Skip to main content
Glama
bitbankinc

bitbank-lab-mcp

Official
by bitbankinc

get_flow_metrics

Compute CVD, aggressor ratio, and buy-sell pressure from trade data for crypto pairs. Specify hours for time range or limit for trade count.

Instructions

[Flow / CVD / Buy-Sell Pressure] 資金フロー分析(flow / CVD / aggressor ratio / buy-sell pressure)。約定データからCVD・アグレッサー比・スパイクを検出。hours(推奨)で時間範囲指定、または limit で件数指定。

データソース制約(bitbank 側仕様): 約定アーカイブ /transactions/{YYYYMMDD} は UTC 暦日単位で、当該 UTC 日の完了後にのみ公開される。進行中の UTC 日(JST 09:00 で切り替わる)の約定は /transactions (latest, 直近約60件) でしか取得できないため、当日区間のカバレッジは限定的(warning で明示される)。

加工契約:

  • 内部で使用する約定列は、取得パスに関わらず timestampMs 昇順にソート済み。

  • latest と date ベースをマージする場合、重複除去キーは timestampMs:price:amount:side(transaction_id は使用しない: 同一約定でも上流エンドポイント間で ID が一致しないケースがあるため)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tzNoAsia/Tokyo
dateNoYYYYMMDD; omit for latest
pairNobtc_jpy
viewNoview は content の量を制御します。量は summary < detailed < full の順で、full は常にそのツールの最重量です。view が structuredContent から**フィールドを削ることはありません**(その view でしか計算しないデータを足すツールはあり、その場合は当該 view の説明に明記しています)。content[0].text は LLM への唯一のチャネルなので、軽い view は「短い表示」ではなく「LLM が明細を受け取らない」を意味します。 本ツールの主対象はバケット列なので、view が決めるのは content のバケット行の量です(集計値・警告・フッタは全 view に出ます)。 - summary(既定): 集計値のみ。バケット行は content に出ない。 - detailed: 集計値 + 直近 bucketsN 件のバケット行(既定 10 / 上限 100)。それより前のバケット行は content に出ない。 - full: 集計値 + 全バケット行。本ツールの最重量。 - compact: 非推奨。view=full + nonZeroOnly=true を使うこと。0.6.0 で削除予定。挙動は view=full + nonZeroOnly=true と同じ。 - buckets: 非推奨。view=detailed を使うこと。0.6.0 で削除予定。挙動は view=detailed と同じ。summary
hoursNo指定した時間数分の約定を取得して分析(例: 8 → 直近8時間)。limit より優先。複数日にまたがる場合も自動で取得します
limitNo取得する約定件数(バケット数ではない)。hours 指定時は無視されます
bucketMsNoバケットの時間幅(ミリ秒)。デフォルト60000=1分間隔
bucketsNNoview=detailed(および deprecated な view=buckets)で content に出す直近バケット行の件数。他の view では無視されます。
nonZeroOnlyNotrue にすると content のバケット行を非ゼロ(buy または sell > 0)のみに絞ります。量ではなく絞り込みの軸なので view とは独立に指定できます。約定が 1 件も無かった区間のバケットは出来高 0 なので content から落ちます(structuredContent には残るので、区間の連続性はそちらで確認できます)。structuredContent は変わりません(全バケットのまま)。view=summary との併用は no-op(バケット行が無いため。エラーにはしません)。
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It explains internal sorting, deduplication logic, data source behavior, view impact on content vs structuredContent, and the meaning of nonZeroOnly. It even warns about weight and deprecated views. This is far beyond typical.

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 description is organized into clear sections (purpose, data source constraints, processing contract) and is front-loaded. While it is long, every section provides necessary operational detail. Some repetition between the main description and schema parameter descriptions exists, but it is not excessive.

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

Completeness5/5

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

Given 9 parameters and no output schema, the description is remarkably complete. It covers parameter interactions, data availability limitations, merge/deduplication logic, and view behavior. An agent would have all necessary information to invoke the tool correctly and interpret the results.

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

Parameters5/5

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

Schema coverage is 78%, but the description adds rich semantics: hours vs limit priority, bucketMs meaning, nonZeroOnly filtering behavior, bucketsN scope, and a detailed breakdown of view options and their effects. This significantly exceeds what the schema alone provides.

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 description opens with a specific purpose: 資金フロー分析(flow / CVD / aggressor ratio / buy-sell pressure), clearly stating it analyzes trade data to compute CVD, aggressor ratio, and buy-sell pressure. It distinguishes itself from sibling tools like get_candles or get_transactions by focusing on flow analysis rather than raw data or price metrics.

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 description explicitly explains parameter usage: hours (recommended) vs limit for range selection, with hours taking priority. It also documents data source constraints and limitations (UTC day boundaries, limited coverage for the current UTC day). It does not explicitly contrast with alternative tools, but given the tool's name and purpose, this is largely self-evident. The deprecated view alternatives are clearly flagged with better replacements.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitbankinc/bitbank-lab-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server