Skip to main content
Glama
bitbankinc

bitbank-lab-mcp

Official
by bitbankinc
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_candles

Fetch historical OHLCV candlestick data for cryptocurrency pairs across timeframes from 1 minute to 1 month, returning a specified number of candles ending before a chosen date in your timezone.

Instructions

[Candles / OHLCV / Candlestick] ローソク足（candles / OHLCV / chart data）を取得。1min〜1monthの各時間足に対応。date は tz（既定 Asia/Tokyo）の暦日として解釈し、その終端以前の limit 本を返す。 詳細は inputSchema を参照。

【重要】バックテストには run_backtest を使用（データ取得〜チャート描画を一括実行）。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tzNoタイムゾーン（既定 Asia/Tokyo）。date パラメータの暦日解釈、isoTimeLocal、keyPoints.date、priceRange.periodStart/End の表示に使用。isoTime は常に UTC ISO。空文字も Asia/Tokyo にフォールバック。UTC が必要な場合は明示的に "UTC" を渡す。Asia/Tokyo
dateNotype により形式が異なる: - 1min/5min/15min/30min/1hour → YYYYMMDD（例: 20251022） - 4hour/8hour/12hour/1day/1week/1month → YYYY（例: 2025） date=YYYYMMDD は tz（既定 Asia/Tokyo）の暦日として解釈します（get_transactions / get_flow_metrics の date は UTC 暦日で基準が異なります）。指定日の終端（23:59:59.999 in tz）以前の limit 本を返します。limit は日数ではなくローソク足本数です。例: 1hour, date=20251002, limit=24 は指定 tz の 10/2 24 本（00:00〜23:00）。 省略時は最新。 （互換: 年足系で YYYYMMDD を渡した場合は先頭4桁を年として使用）
pairYes
typeYes
viewNoview は content の量を制御します。量は summary < detailed < full の順で、full は常にそのツールの最重量です。view が structuredContent から**フィールドを削ることはありません**（その view でしか計算しないデータを足すツールはあり、その場合は当該 view の説明に明記しています）。content[0].text は LLM への唯一のチャネルなので、軽い view は「短い表示」ではなく「LLM が明細を受け取らない」を意味します。 - full（既定）: サマリ本文（全 OHLCV を 1 行 1 本の圧縮形式で列挙）＋ 価格レンジ / キーポイント / 出来高統計 / フッタ ＋ 先頭 5 本の JSON サンプル。本ツールの最重量。 - items: 非推奨。view=full + format=json を使うこと。0.4.0 で削除予定。挙動は view=full + format=json と同じ（content は全件の pretty JSON のみで、サマリ本文・価格レンジ・キーポイント・出来高統計・フッタは出ない）。 集計だけを返す軽量 summary は未実装（量を絞る手段は limit）。full
limitNoデフォルト 200。1〜10000 の整数。type により実上限が変わる: 1min〜1hour は最大 10000（複数日取得）、4hour〜1month は最大 5000（複数年取得）、それ以外は 1000。実上限を超えると user エラー。
formatNocontent の形式。text（既定）: 散文 / json: pretty JSON。json は機械可読性のために**トークンを払う**オプションで、同じデータでも text より必ず多くなります（削減オプションではありません）。量は format ではなく view と limit が決めます。text

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.5.0
    • changedInput schema / properties / date / description
      Previous value: -"type により形式が異なる:\n- 1min/5min/15min/30min/1hour → YYYYMMDD（例: 20251022）\n- 4hour/8hour/12hour/1day/1week/1month → YYYY（例: 2025）\ndate=YYYYMMDD は tz（既定 Asia/Tokyo）の暦日として解釈します。指定日の終端（23:59:59.999 in tz）以前の limit 本を返します。limit は日数ではなくローソク足本数です。例: 1hour, date=20251002, limit=24 は指定 tz の 10/2 24 本（00:00〜23:00）。\n省略時は最新。\n（互換: 年足系で YYYYMMDD を渡した場合は先頭4桁を年として使用）"New value: +"type により形式が異なる:\n- 1min/5min/15min/30min/1hour → YYYYMMDD（例: 20251022）\n- 4hour/8hour/12hour/1day/1week/1month → YYYY（例: 2025）\ndate=YYYYMMDD は tz（既定 Asia/Tokyo）の暦日として解釈します（get_transactions / get_flow_metrics の date は UTC 暦日で基準が異なります）。指定日の終端（23:59:59.999 in tz）以前の limit 本を返します。limit は日数ではなくローソク足本数です。例: 1hour, date=20251002, limit=24 は指定 tz の 10/2 24 本（00:00〜23:00）。\n省略時は最新。\n（互換: 年足系で YYYYMMDD を渡した場合は先頭4桁を年として使用）"
    • changedInput schema / properties / view / description
      Previous value: -"view は content の量を制御します。量は summary < detailed < full の順で、full は常にそのツールの最重量です。view が structuredContent から**フィールドを削ることはありません**（その view でしか計算しないデータを足すツールはあり、その場合は当該 view の説明に明記しています）。content[0].text は LLM への唯一のチャネルなので、軽い view は「短い表示」ではなく「LLM が明細を受け取らない」を意味します。\n- full（既定）: サマリ本文（全 OHLCV を 1 行 1 本の圧縮形式で列挙）＋ 価格レンジ / キーポイント / 出来高統計 / フッタ ＋ 先頭 5 本の JSON サンプル。本ツールの最重量。\n- items: 非推奨。view=full + format=json を使うこと。0.6.0 で削除予定。挙動は view=full + format=json と同じ（content は全件の pretty JSON のみで、サマリ本文・価格レンジ・キーポイント・出来高統計・フッタは出ない）。\n集計だけを返す軽量 summary は未実装（量を絞る手段は limit）。"New value: +"view は content の量を制御します。量は summary < detailed < full の順で、full は常にそのツールの最重量です。view が structuredContent から**フィールドを削ることはありません**（その view でしか計算しないデータを足すツールはあり、その場合は当該 view の説明に明記しています）。content[0].text は LLM への唯一のチャネルなので、軽い view は「短い表示」ではなく「LLM が明細を受け取らない」を意味します。\n- full（既定）: サマリ本文（全 OHLCV を 1 行 1 本の圧縮形式で列挙）＋ 価格レンジ / キーポイント / 出来高統計 / フッタ ＋ 先頭 5 本の JSON サンプル。本ツールの最重量。\n- items: 非推奨。view=full + format=json を使うこと。0.4.0 で削除予定。挙動は view=full + format=json と同じ（content は全件の pretty JSON のみで、サマリ本文・価格レンジ・キーポイント・出来高統計・フッタは出ない）。\n集計だけを返す軽量 summary は未実装（量を絞る手段は limit）。"
  2. Changed3 schema fields 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"
    • addedInput schema / properties / format
      Added value: +{
+  "default": "text",
+  "description": "content の形式。text（既定）: 散文 / json: pretty JSON。json は機械可読性のために**トークンを払う**オプションで、同じデータでも text より必ず多くなります（削減オプションではありません）。量は format ではなく view と limit が決めます。",
+  "enum": [
+    "text",
+    "json"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / view / description
      Added value: +"view は content の量を制御します。量は summary < detailed < full の順で、full は常にそのツールの最重量です。view が structuredContent から**フィールドを削ることはありません**（その view でしか計算しないデータを足すツールはあり、その場合は当該 view の説明に明記しています）。content[0].text は LLM への唯一のチャネルなので、軽い view は「短い表示」ではなく「LLM が明細を受け取らない」を意味します。\n- full（既定）: サマリ本文（全 OHLCV を 1 行 1 本の圧縮形式で列挙）＋ 価格レンジ / キーポイント / 出来高統計 / フッタ ＋ 先頭 5 本の JSON サンプル。本ツールの最重量。\n- items: 非推奨。view=full + format=json を使うこと。0.6.0 で削除予定。挙動は view=full + format=json と同じ（content は全件の pretty JSON のみで、サマリ本文・価格レンジ・キーポイント・出来高統計・フッタは出ない）。\n集計だけを返す軽量 summary は未実装（量を絞る手段は limit）。"
  3. First observedv0.1.1

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the disclosure burden and excels: it defines date as a tz-calendar-day with end-of-day cutoff, clarifies that limit counts candles rather than days, details view/full vs items behavior and JSON token cost, and notes per-timeframe limit caps. It also flags items as deprecated. This goes well beyond simple 'get' semantics.

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 description is compact: one purpose sentence, one date/limit summary, a pointer to the schema, and a backtest warning. The pointer avoids duplicating the schema, but the date/limit sentence repeats what the date and limit parameter descriptions already say, a minor redundancy.

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?

The tool definition is very rich for a retrieval tool: it covers timeframes, date/timezone semantics, limit caps, view modes, output format, and deprecation. It lacks an output schema, but the view parameter description specifies the full return content, including summary body, price range, key points, volume stats, footer, and JSON sample. The main description's exclusions are limited to no auth/error details, which is acceptable for a read-only data getter.

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 already documents tz, date, view, limit, and format in detail (71% coverage), so the description's own parameter notes, such as date as a tz calendar day and limit as candle count, largely duplicate the schema. Pair and type remain undescribed in both the description and schema apart from the enum and required flags, and the description adds nothing for pair.

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 '[Candles / OHLCV / Candlestick] ローソク足（candles / OHLCV / chart data）を取得', naming a specific verb (取得/get) and resource (candles/OHLCV), and states supported timeframes 1min〜1month. It also explicitly routes backtesting to run_backtest, which helps distinguish it from a likely sibling.

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?

It explicitly says 'バックテストには run_backtest を使用（データ取得〜チャート描画を一括実行）', giving one concrete when-not and alternative. It also advises that items is deprecated and to use view=full + format=json. However, it does not broadly enumerate when to prefer get_candles over other data tools such as get_ticker or get_orderbook.

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