How do I use boj-jstat-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@boj-jstat-mcp get the dollar-yen exchange rate for December 2025" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

boj-jstat-mcp

by Shigurex

Overview Schema Related Servers Score Discussions

TypeScript

boj-jstat-mcp

日本銀行時系列統計データ検索サイトのAPI機能を利用するMCP（Model Context Protocol）サーバーです。

金利、マネーサプライ、為替レート、短観、国際収支、物価指数など、40以上の日銀統計データベースにClaude/CodexなどのAIアシスタントから直接アクセスできます。

クイックスタート

git clone なしでそのまま使えます。npx -y boj-jstat-mcp@latest を指定すると npm から取得して起動できます。

注意（2026-02-25時点）: boj-mcp@latest は別プロジェクト（solved.ac向け）であり、このリポジトリの日銀MCPではありません。

Claude Desktop

claude_desktop_config.json に以下を追加：

{
  "mcpServers": {
    "boj": {
      "command": "npx",
      "args": ["-y", "boj-jstat-mcp@latest"]
    }
  }
}

Claude Code

追加:

claude mcp add boj -- npx -y boj-jstat-mcp@latest

確認:

claude mcp list

削除:

claude mcp remove boj

Codex CLI

追加:

codex mcp add boj -- npx -y boj-jstat-mcp@latest

確認:

codex mcp list
codex mcp get boj

削除:

codex mcp remove boj

Related MCP server: jquants-mcp

使い方（推奨フロー）

boj_list_databases でDB候補を絞る
boj_get_metadata を limit=20-50 程度で呼び、系列コード/レイヤーを特定
boj_get_data_code または boj_get_data_layer で本取得
NEXTPOSITION が返ったら startPosition でページング

使用例

物価関連のDBを探す：

「物価に関する日銀のデータベースを一覧表示して」

短観DIデータを取得：

「2024年第1四半期から2025年第4四半期までの短観・大企業製造業の業況判断DIを取得して」

為替レートを確認：

「2025年12月のドル円為替レートデータを見せて」

国際収支を参照：

「2025年1月の国際収支統計から経常収支を取得して」

アクセス可能なデータベース一覧

1. 金利（預金・貸出関連）

DBコード	説明
IR01	基準割引率および基準貸付利率（従来「公定歩合」として掲載されていたもの）の推移
IR02	預金種類別店頭表示金利の平均年利率等
IR03	定期預金の預入期間別平均金利
IR04	貸出約定平均金利

2. マーケット関連

DBコード	説明
FM01	無担保コールO/N物レート（毎営業日）
FM02	短期金融市場金利
FM03	短期金融市場残高
FM04	コール市場残高
FM05	公社債発行・償還および現存額
FM06	公社債消化状況（利付国債）
FM07	（参考）国債窓口販売額・窓口販売率（2004年1月まで）
FM08	外国為替市況
FM09	実効為替レート

3. 決済関連

DBコード	説明
PS01	各種決済
PS02	フェイルの発生状況

4. 預金・マネー・貸出

DBコード	説明
MD01	マネタリーベース
MD02	マネーストック
MD03	マネタリーサーベイ
MD04	（参考）マネーサプライ（M2+CD）増減と信用面の対応
MD05	通貨流通高
MD06	日銀当座預金増減要因と金融調節（実績）
MD07	準備預金額
MD08	業態別の日銀当座預金残高
MD09	マネタリーベースと日本銀行の取引
MD10	預金者別預金
MD11	預金・現金・貸出金
MD12	都道府県別預金・現金・貸出金
MD13	貸出・預金動向
MD14	定期預金の残高および新規受入高
LA01	貸出先別貸出金
LA02	日本銀行貸出
LA03	その他貸出残高
LA04	コミットメントライン契約額、利用額
LA05	主要銀行貸出動向アンケート調査

5. 金融機関バランスシート

DBコード	説明
BS01	日本銀行勘定
BS02	民間金融機関の資産・負債

6. 資金循環

DBコード	説明
FF	資金循環

7. その他の日本銀行関連

DBコード	説明
OB01	日本銀行の対政府取引
OB02	日本銀行が受入れている担保の残高

8. 短観

DBコード	説明
CO	短観

9. 物価

DBコード	説明
PR01	企業物価指数
PR02	企業向けサービス価格指数
PR03	製造業部門別投入・産出物価指数
PR04	＜サテライト指数＞最終需要・中間需要物価指数

10. 財政関連

DBコード	説明
PF01	財政資金収支
PF02	政府債務

11. 国際収支・BIS関連

DBコード	説明
BP01	国際収支統計
BIS	BIS国際資金取引統計および国際与信統計の日本分集計結果
DER	デリバティブ取引に関する定例市場報告

12. その他

DBコード	説明
OT	その他

ツール一覧

`boj_list_databases` — DB一覧表示

利用可能な日銀統計データベースの一覧を表示します。APIコール不要（静的データ）。

パラメータ	必須	説明
`category`	いいえ	カテゴリでフィルタ
`search`	いいえ	コードまたは名前で検索

`boj_get_metadata` — メタデータ取得

データベースのメタデータ（系列コード、名称、単位、期種、階層構造）を取得します。返却には SERIES_CODE を持つ行のみを表示し、boj_get_data_code で使えない見出し行は除外します。

パラメータ	必須	説明
`db`	はい	DBコード（例：`CO`）
`lang`	いいえ	`jp`（デフォルト）または `en`
`limit`	いいえ	返却件数上限（デフォルト200、最大1000）

`boj_get_data_code` — 系列コード指定データ取得

系列コードを指定して時系列データを取得します。1リクエストあたり最大250系列/60,000データポイント。 code は必ず boj_get_metadata で取得した SERIES_CODE をそのまま指定してください（DB接頭辞や引用符区切りの旧形式は不可）。無効コード時は近い候補を提示し、近似一致が十分高い場合は自動補正して再試行します。

パラメータ	必須	説明
`db`	はい	DBコード
`code`	はい	カンマ区切りの系列コード（同一期種のみ）
`lang`	いいえ	`jp`（デフォルト）または `en`
`startDate`	いいえ	開始期（形式は期種に依存）
`endDate`	いいえ	終了期
`startPosition`	いいえ	ページネーション（前回のNEXTPOSITION値）

`boj_get_data_layer` — 階層指定データ取得

階層構造を指定して時系列データを取得します。ワイルドカード * 対応。最大1,250系列/60,000データポイント。

パラメータ	必須	説明
`db`	はい	DBコード
`layer`	はい	カンマ区切りの階層値（例：`1,1,1`）、`*` で全指定
`frequency`	はい	`CY`, `FY`, `CH`, `FH`, `Q`, `M`, `W`, `D`
`lang`	いいえ	`jp`（デフォルト）または `en`
`startDate`	いいえ	開始期
`endDate`	いいえ	終了期
`startPosition`	いいえ	ページネーション（前回のNEXTPOSITION値）

日付パラメータの仕様（重要）

BOJ API の仕様上、startDate / endDate は期種単位の指定です。
YYYY-MM-DD と YYYYMMDD を渡した場合、サーバー側で期種フォーマットへ正規化します。
D（日次）/W（週次）系列でも、BOJ API には YYYYMM 形式で問い合わせます（返却データ自体は日付単位）。

レート制限

BOJの「高頻度アクセスは避けてください」というガイドラインに準拠するため、トークンバケット方式のレートリミッター（容量5、毎秒1トークン補充）を内蔵しています。並列リクエスト時も内部キューで制御し、過剰送信を防ぎます。

動作要件

Node.js 18.0.0以上

クレジット

このサービスは、日本銀行時系列統計データ検索サイトの API 機能を使用しています。サービスの内容は日本銀行によって保証されたものではありません。

Available Tools

4 tools

boj_get_data_codeA

Fetch time series data by SERIES_CODE(s). All specified codes must share the same frequency. Returns up to 250 series / 60,000 data points per request. If a code is invalid, the server tries metadata-assisted correction for close matches and returns concrete suggestions.

ParametersJSON Schema

Name	Required	Description
`db`	Yes	Database code (e.g. 'CO' for Tankan)
`code`	Yes	Comma-separated SERIES_CODE values from boj_get_metadata (e.g. 'TK99F1000601GCQ01000,TK99F2000601GCQ01000'). Do not prefix DB names or include quote-delimited legacy code formats. All codes must share the same frequency. Max 250 codes.
`lang`	No	Language: 'jp' (Japanese, default) or 'en' (English)
`endDate`	No	End date. Same format as startDate. Auto-conversion applies.
`startDate`	No	Start date. Format: YYYY (annual), YYYYHH (semi-annual), YYYYQQ (quarterly), YYYYMM (monthly/weekly/daily period filter). YYYY-MM-DD and YYYYMMDD are auto-converted to BOJ-compatible period format.
`startPosition`	No	Pagination: start position from NEXTPOSITION of a previous response

TDQS

A3.5/5.0

Behavior3/5

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

Discloses limits (250 series, 60k points) and error-handling behavior (auto-correction, suggestions). With no annotations, this is adequate but does not mention authentication, rate limits, or idempotency.

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?

Three sentences, each serving a purpose: purpose, constraint, error handling. Concise and well-structured.

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

Completeness3/5

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

No output schema, so description should explain return values; it hints at pagination via startPosition but lacks details on response format. For 6-param tool, sufficient but not complete.

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 covers all parameters with descriptions. Description adds cross-parameter constraints (same frequency) and system limits (max 250 codes), going beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it fetches time series data by SERIES_CODE, which distinguishes it from siblings like boj_get_metadata (metadata) and boj_list_databases (listing). However, it does not explicitly contrast with boj_get_data_layer.

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

Usage Guidelines3/5

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

Implies usage after obtaining metadata codes, and mentions constraints (same frequency, limits). But lacks explicit when-to-use or when-not-to-use guidance compared to sibling tools.

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

boj_get_data_layerA

Fetch time series data by layer (hierarchical structure). Useful for browsing data by category within a database. Supports wildcard '*'. Returns up to 1,250 series / 60,000 data points per request.

ParametersJSON Schema

Name	Required	Description
`db`	Yes	Database code (e.g. 'BP01' for Balance of Payments)
`lang`	No	Language: 'jp' (Japanese, default) or 'en' (English)
`layer`	Yes	Layer specification as comma-separated values (e.g. '1,1,1'). Use '*' as wildcard for any layer. Layer 1 is required; layers 2-5 are optional.
`endDate`	No	End date. Same format as startDate.
`frequency`	Yes	Frequency: CY=calendar year, FY=fiscal year, CH=calendar semi-annual, FH=fiscal semi-annual, Q=quarterly, M=monthly, W=weekly, D=daily
`startDate`	No	Start date. Format depends on frequency: YYYY (annual), YYYYHH (semi-annual), YYYYQQ (quarterly), YYYYMM (monthly/weekly/daily period filter). YYYY-MM-DD and YYYYMMDD are auto-normalized.
`startPosition`	No	Pagination: start position from NEXTPOSITION of a previous response

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses limits (1,250 series / 60,000 data points), wildcard support, and pagination via startPosition. It does not explicitly state read-only behavior, but the 'fetch' verb and lack of mutation language suffice.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with front-loaded purpose: first sentence states action, second adds usage context, third gives key limits and features. No wasted words.

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?

Given 7 parameters and no output schema, the description covers main behaviors (limits, wildcard, pagination) but omits explanation of NEXTPOSITION origin and date format normalization details. Still fairly complete for a data retrieval tool.

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 coverage is 100%, so baseline is 3. The description adds context about hierarchical browsing and limits but does not provide parameter-specific meaning beyond what the schema already includes, such as the layer format and wildcard use already detailed in the schema.

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 clearly states the verb 'Fetch' and resource 'time series data by layer', and explains the hierarchical structure and browsing by category, distinguishing it from sibling tools like boj_list_databases and boj_get_data_code.

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 clear context for when to use the tool: 'useful for browsing data by category within a database'. This guides the agent toward the intended use case, though it does not explicitly exclude other scenarios or mention alternatives.

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

boj_get_metadataA

Get metadata (series codes, names, units, frequencies, layer structure) for a BOJ database. Use this to discover available series codes and understand the database structure before fetching actual data. NOTE: Large databases like CO (Tankan, 168k series) require a small limit (e.g. 20-50) to avoid overwhelming responses — use layer-based queries to navigate them.

ParametersJSON Schema

Name	Required	Description
`db`	Yes	Database code (e.g. 'CO' for Tankan, 'FM08' for FX rates)
`lang`	No	Language: 'jp' (Japanese, default) or 'en' (English)
`limit`	No	Maximum number of series entries to return. Defaults to 200 (max: 1000). Large databases (e.g. CO/Tankan has 168k entries) should use smaller limits to avoid overwhelming responses.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that large databases may overwhelm responses and recommends using a small limit or layer-based queries. This addresses a key behavioral trait (response size), though it does not mention error handling or authentication.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy. First sentence defines the tool's output, second provides actionable guidance. Information is front-loaded and every sentence serves a purpose.

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?

Given the tool's complexity (3 params, no output schema), the description covers purpose, usage timing, and a critical caution about large databases. It does not detail output structure or error scenarios, but is sufficient for a metadata discovery tool.

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 coverage is 100%, and the description adds value by explaining the purpose of parameters like db (database code) and limit (with specific guidance for large databases). It also mentions 'layer structure' in context, enriching the understanding beyond the schema.

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 clearly states 'Get metadata (series codes, names, units, frequencies, layer structure) for a BOJ database', specifying the verb and resource. It differentiates from siblings by indicating this is for discovering structure before fetching data, unlike boj_list_databases, boj_get_data_code, or boj_get_data_layer.

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 advises using this tool to discover available series codes before fetching data, and includes a specific caution for large databases (e.g., CO/Tankan) to use small limits. It lacks explicit exclusion criteria or direct comparison with siblings, but the context implies when to use it.

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

boj_list_databasesA

List all available BOJ statistical databases. Use this first to find the correct DB code before querying data. No API call needed — uses a static list of 40+ databases.

ParametersJSON Schema

Name	Required	Description	Default
`search`	No	Search term to filter databases by code or name (case-insensitive)
`category`	No	Filter by category (e.g. 'Interest Rates', 'Money Market', 'Prices')

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description discloses that 'No API call needed — uses a static list of 40+ databases,' which informs the agent about the tool's lightweight nature and scope. This adds value beyond expectations, though more details like update frequency could improve it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description consists of two sentences, front-loading the main purpose and usage instruction without extraneous detail. Every sentence is functional and efficient.

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 the tool's simplicity (no output schema, optional parameters, static data), the description fully covers its purpose, usage context, and behavioral traits. No additional information is necessary for an agent to use it correctly.

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 coverage is 100% with both parameters ('search' and 'category') having descriptions. The tool description adds no extra parameter meaning, so it meets the baseline for a well-documented schema.

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 clearly states 'List all available BOJ statistical databases' with a specific verb and resource. It distinguishes from siblings which are about getting data code, layer, and metadata, making its role as a discovery tool unambiguous.

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 advises 'Use this first to find the correct DB code before querying data,' providing clear when-to-use guidance. While no explicit when-not-to-use or alternatives are given, the sibling tools are for different purposes, so this is sufficient.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jul 24, 2026
- First observedboj_get_data_code
- First observedboj_get_data_layer
- First observedboj_get_metadata
- First observedboj_list_databases

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing databases, fetching data by code, fetching data by layer, and retrieving metadata. There is no overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'boj_verb_object' pattern (e.g., boj_list_databases, boj_get_data_code), making it easy for agents to predict function.

Tool Count5/5

Four tools is well-scoped for a statistical data server, covering essential operations without redundancy or bloat.

Completeness5/5

The tool set covers the full workflow: discover databases, explore metadata, and retrieve data via two complementary methods (by code and by layer). No obvious gaps.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
hithereiamaliff-mcp-datagovmy BOAuth
ai.smithery
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
Government Data Open Data
23
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202

Related MCP Servers

estat-mcp
ajtgjmdjp
A
license
Not graded
quality
B
maintenance
MCP server for Japan's e-Stat (Government Statistics Portal). Search statistical datasets, retrieve data tables, and access metadata from official Japanese government statistics.
Updated 14 days ago (2026-08-23 08:23 UTC)
9
Apache 2.0
jquants-mcp
Finance Research & Data
shigechika
A
license
A
quality
B
maintenance
An MCP server that retrieves Japanese stock market data via J-Quants API v2.
Updated 5 days ago (2026-09-01 09:43 UTC)
55
2
MIT
e-Stat MCP server
Government Data Open Data Research & Data
cygkichi
A
license
B
quality
F
maintenance
MCP server for accessing Japanese government statistics portal 'e-Stat' API, enabling language models to search and retrieve statistical data.
Updated a year ago (2025-04-19 15:45 UTC)
5
20
MIT
Synergic APIs MCP Serverofficial
Finance Government Data Open Data
Synergic-APIs
A
license
A
quality
B
maintenance
MCP server providing official US economic data including CPI inflation, famous prices, national debt, and Treasury interest rates. Enables AI agents to query historical and latest economic statistics via natural language.
Updated a month ago (2026-08-02 19:46 UTC)
8
59
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Shigurex/boj_jstat_mcp'

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

boj-jstat-mcp

クイックスタート

Claude Desktop

Claude Code

Codex CLI

使い方（推奨フロー）

使用例

アクセス可能なデータベース一覧

1. 金利（預金・貸出関連）

2. マーケット関連

3. 決済関連

4. 預金・マネー・貸出

5. 金融機関バランスシート

6. 資金循環

7. その他の日本銀行関連

8. 短観

9. 物価

10. 財政関連

11. 国際収支・BIS関連

12. その他

ツール一覧

boj_list_databases — DB一覧表示

boj_get_metadata — メタデータ取得

boj_get_data_code — 系列コード指定データ取得

boj_get_data_layer — 階層指定データ取得

日付パラメータの仕様（重要）

レート制限

動作要件

クレジット

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Synergic APIs MCP Serverofficial

Latest Blog Posts

MCP directory API

`boj_list_databases` — DB一覧表示

`boj_get_metadata` — メタデータ取得

`boj_get_data_code` — 系列コード指定データ取得

`boj_get_data_layer` — 階層指定データ取得