Skip to main content
Glama
bitbankinc

bitbank-lab-mcp

Official
by bitbankinc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

analyze_volume_profile

Compute volume profile, VWAP deviation bands, POC, and value area to reveal price levels with concentrated trading activity and trade size distribution.

Instructions

[Volume Profile / VWAP / POC] 出来高プロファイル分析（volume profile / VWAP / POC / value area）。VWAP±σバンド・価格帯別出来高・約定サイズ分布を算出。hours で期間指定（デフォルト4h、最大24h）。

期間指定の使い分け:

  • hours: 現在時刻起点の相対窓（最大24h）。

  • since / until: オフセット付き ISO8601 の絶対時刻区間（例: since=2026-08-01T00:00:00Z, until=2026-08-02T00:00:00Z）。過去の特定区間を全件集計する唯一の手段。until は排他（[since, until)）で省略時は現在時刻まで。最大 7 日。limit は適用しない。

  • hours と since/until は併用不可（併用すると user エラー）。since/until に YYYYMMDD 形式は使えない（暦日の基準がツール間で割れているため、絶対時刻はオフセット必須の ISO8601 のみ受け付ける）。

データソース制約（bitbank 側仕様）: 約定アーカイブ /transactions/{YYYYMMDD} は UTC 暦日単位で、当該 UTC 日の完了後にのみ公開される。完了済み UTC 日は全件（1日あたり数千件）を集計に使う。進行中の UTC 日（JST 09:00 で切り替わる）は /transactions (latest, 直近約60件) のみ。

カバレッジ申告: params.timeRange は durationMin（先頭〜末尾のスパン）に加えて coveredMin（実データがある区間の合計）/ gapMin / segments を返す。欠損があれば meta.warning（取得層）と meta.warnings（計算層: 集計値がカバー区間のみ由来である旨）で明示される。

加工契約: 内部の約定列は timestampMs 昇順にソート済み。latest と date ベースのマージ時の重複除去キーは timestampMs:price:amount:side（transaction_id は使用しない）。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tzNoAsia/Tokyo
binsNoVolume Profile の価格帯分割数
pairNobtc_jpy
hoursNo直近N時間分の約定を取得（デフォルト4h）。**現在時刻起点**の相対窓。limit より優先。since/until とは併用不可（併用時は user エラー）
limitNo取得する約定件数。**hours / since・until のいずれも指定しない件数ベース取得（＝直近 N 件）でのみ有効**で、区間指定時は無視されます（区間の全件を集計）。上限 2000 件は BTC/JPY で 6〜8.5 時間分に相当します。それより長い窓は件数ではなく hours / since・until で指定してください
sinceNo取得区間の開始時刻（**含む**）。オフセット付き ISO8601 のみ（例: 2026-08-01T00:00:00Z / 2026-08-01T09:00:00+09:00）。YYYYMMDD は不可 — 暦日の基準がツール間で割れている（約定系ツールの date は UTC 暦日、get_candles の date は tz 引数の暦日）ため、絶対時刻はオフセット必須にして解釈のブレを排除している。hours / date とは併用不可。since〜until は最大 7 日。指定時は limit を適用しない（区間の全件を集計）
untilNo取得区間の終端時刻（**含まない**: [since, until)）。オフセット付き ISO8601 のみ。省略時は現在時刻まで。排他区間なので、連続する区間を続けて要求しても境界の約定が二重計上されない（例: since=2026-08-01T00:00:00Z, until=2026-08-02T00:00:00Z は UTC 8/1 のちょうど 1 日）。since 無しの until 単独指定は user エラー。未来時刻も user エラー（現在時刻までを対象にするなら until を省略する）
valueAreaPctNoValue Area のカバー率（デフォルト70%）

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.5.0
    • changedInput schema / properties / hours / description
      Previous value: -"直近N時間分の約定を取得（デフォルト4h）。limit より優先"New value: +"直近N時間分の約定を取得（デフォルト4h）。**現在時刻起点**の相対窓。limit より優先。since/until とは併用不可（併用時は user エラー）"
    • changedInput schema / properties / limit / description
      Previous value: -"取得する約定件数。hours 指定時は無視"New value: +"取得する約定件数。**hours / since・until のいずれも指定しない件数ベース取得（＝直近 N 件）でのみ有効**で、区間指定時は無視されます（区間の全件を集計）。上限 2000 件は BTC/JPY で 6〜8.5 時間分に相当します。それより長い窓は件数ではなく hours / since・until で指定してください"
    • addedInput schema / properties / since
      Added value: +{
+  "description": "取得区間の開始時刻（**含む**）。オフセット付き ISO8601 のみ（例: 2026-08-01T00:00:00Z / 2026-08-01T09:00:00+09:00）。YYYYMMDD は不可 — 暦日の基準がツール間で割れている（約定系ツールの date は UTC 暦日、get_candles の date は tz 引数の暦日）ため、絶対時刻はオフセット必須にして解釈のブレを排除している。hours / date とは併用不可。since〜until は最大 7 日。指定時は limit を適用しない（区間の全件を集計）",
+  "pattern": "^(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2})(?::(\\d{2})(?:\\.(\\d+))?)?(Z|[+-]\\d{2}:\\d{2})$",
+  "type": "string"
+}
    • addedInput schema / properties / until
      Added value: +{
+  "description": "取得区間の終端時刻（**含まない**: [since, until)）。オフセット付き ISO8601 のみ。省略時は現在時刻まで。排他区間なので、連続する区間を続けて要求しても境界の約定が二重計上されない（例: since=2026-08-01T00:00:00Z, until=2026-08-02T00:00:00Z は UTC 8/1 のちょうど 1 日）。since 無しの until 単独指定は user エラー。未来時刻も user エラー（現在時刻までを対象にするなら until を省略する）",
+  "pattern": "^(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2})(?::(\\d{2})(?:\\.(\\d+))?)?(Z|[+-]\\d{2}:\\d{2})$",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.4.1
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so thoroughly. It discloses data source constraints (bitbank UTC daily archives, latest ~60 trades for in-progress days), coverage reporting (durationMin, coveredMin, gapMin, segments, meta.warning/warnings), and a processing contract (timestampMs sorting, dedup key 'timestampMs:price:amount:side'). These details reveal how the tool behaves under partial data and how results should be interpreted, far beyond what annotations could provide.

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 lengthy but well-organized: it front-loads the core purpose, then uses bolded section headers (期間指定の使い分け, データソース制約, カバレッジ申告, 加工契約) to structure dense information. Every sentence adds value for a complex 8-parameter tool with no annotations. It loses one point because the sheer volume of detail, especially the dedup key and data source internals, could be overwhelming, though it is justified given the tool's complexity.

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?

Despite having no output schema and no annotations, the description fully equips the agent to use the tool correctly. It explains what the output contains (timeRange metadata, meta.warning/warnings), how data sourcing affects results (coverage gaps), parameter boundaries and error cases, and the internal sorting/dedup contract. For a tool of this complexity, nothing essential is missing.

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?

Schema description coverage is 75%, with detailed schema descriptions for bins, hours, limit, since, until, and valueAreaPct. The description adds meaning beyond the schema by explaining how these parameters interact: hours as a relative window, since/until as absolute intervals with exclusive boundaries, limit only valid without time ranges, and the specific reason YYYYMMDD is rejected. This contextualizes the parameter semantics in a way the schema alone does not.

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 immediately identifies the tool's function: '出来高プロファイル分析（volume profile / VWAP / POC / value area）' followed by the specific calculations 'VWAP±σバンド・価格帯別出来高・約定サイズ分布を算出'. This is a specific verb+resource combination that distinguishes it from sibling analysis tools like analyze_candle_patterns or analyze_indicators, which address entirely different 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 provides explicit guidance on parameter selection: hours vs since/until vs limit, including mutual exclusivity ('併用不可') and error conditions (since without until, future times). It also states that since/until is '過去の特定区間を全件集計する唯一の手段' (the only way to aggregate complete past intervals), which is a strong usage directive. However, it does not explicitly compare this tool against sibling tools beyond a passing mention of get_candles for date semantics, missing the opportunity to say 'use this tool when you need volume profile'.

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