ロシア中央銀行（Центральный банк РФ, CBR）の公開データ（為替レート、政策金利、インフレ率、およびコンパクトなマクロ統計スナップショット）をAIエージェントに提供するModel Context Protocol (MCP) サーバー。
mcp-cbr-rates は、ロシアのフィンテックエコシステムに焦点を当てた atomno ファミリーのMCPサーバーの一部です。完全にオープンソースであり、APIキーは不要で、CBRの公式公開エンドポイントに基づいて構築されています。
厳格なPydanticスキーマを備えた5つの高品質なMCPツール: get_rate, history_rates, key_rate, inflation, statistics。
内蔵TTL（Time-To-Live）キャッシュ: ソースへの負荷を考慮し、日次レートは1時間、過去の時系列データは24時間キャッシュします。
5xxエラー時の自動リトライ機能を備えた非同期 httpx トランスポート。
defusedxml による安全なXML解析。
respx でモックされたHTTPテストを含む50以上のユニットテスト、80%以上のカバレッジ。
シークレット、テレメトリ、サードパーティのトラッカーは一切なし。
Related MCP server: mcp-fns-check
git clone https://github.com/atomno-labs/mcp-cbr-rates.git
cd mcp-cbr-rates
pip install -e .
mcp-cbr-rates # starts the MCP server over stdio.cursor/mcp.json（またはグローバルな ~/.cursor/mcp.json）に以下を追加します：
{
"mcpServers": {
"cbr-rates": {
"command": "mcp-cbr-rates"
}
}
}claude_desktop_config.json に追加します：
{
"mcpServers": {
"cbr-rates": {
"command": "mcp-cbr-rates"
}
}
}Windowsの場合、設定ファイルは %APPDATA%\Claude\claude_desktop_config.json にあり、macOSの場合は ~/Library/Application Support/Claude/claude_desktop_config.json にあります。
claude mcp add cbr-rates -- mcp-cbr-rates名前 | 入力 | 戻り値 |
|
|
|
|
|
|
|
|
|
|
|
|
| (なし) |
|
平易な英語での例：
"2024年4月25日の公式EURレートはいくらでしたか？" ツール:
get_rate(char_code="EUR", on_date="2024-04-25")
"過去90日間のUSD-RUBの日次レートをプロットして。" ツール:
history_rates(char_code="USD", date_from=..., date_to=...)
"最新の政策金利、USD/EUR/CNY、インフレ率を一度に教えて。" ツール:
statistics()
history_rates の期間は最大366日に制限されています。それ以上の期間が必要な場合は、ツールを繰り返し呼び出してください。
すべての設定はオプションであり、環境変数から読み込まれます：
変数 | デフォルト | 説明 |
|
| CBR呼び出しのHTTPタイムアウト（秒）。 |
|
| 日次レートのキャッシュTTL（秒）。 |
|
| 過去の時系列データおよびSOAPレスポンスのキャッシュTTL（秒）。 |
|
| 標準的なPythonログレベル。 |
設定すべきAPIキーはありません。ここで使用されるすべてのCBRエンドポイントは公開されています。
git clone https://github.com/atomno-labs/mcp-cbr-rates.git
cd mcp-cbr-rates
python -m venv .venv && source .venv/bin/activate # or .\.venv\Scripts\activate on Windows
pip install -e ".[dev]"
pytest --cov=src/mcp_cbr_ratesレイアウト:
apps/mcp-cbr-rates/
├── src/mcp_cbr_rates/
│ ├── server.py # FastMCP entry point, tool registration
│ ├── tools.py # high-level async tools with caching
│ ├── client.py # httpx wrapper around CBR XML / SOAP / HTML endpoints
│ ├── schemas.py # Pydantic v2 models for inputs & outputs
│ ├── cache.py # async TTL cache
│ ├── currency_codes.py # static ISO → CBR id map (with dynamic fallback)
│ └── errors.py # typed exception hierarchy
└── tests/ # respx-mocked unit tests + fixtureshttps://www.cbr.ru/scripts/XML_daily.asp — 日次為替レート。
https://www.cbr.ru/scripts/XML_dynamic.asp — 過去の為替時系列データ。
https://www.cbr.ru/scripts/XML_valFull.asp — 通貨コード検索。
https://www.cbr.ru/DailyInfoWebServ/DailyInfo.asmx — CBR政策金利用SOAPサービス。
https://www.cbr.ru/hd_base/infl/ — 月次前年同月比インフレ率テーブル。
すべてのエンドポイントは読み取り専用で無料です。
このプロジェクトは、ロシア中央銀行とは一切関係ありません。公開されているデータを最大限の努力でラップした非公式なものです。自己責任でご利用ください。作成者は、本サーバーを通じて提供されるデータの鮮度、正確性、または適用性について一切の責任を負いません。
CBRのHTMLまたはXMLスキーマが変更された場合、このパッケージが更新されるまで個々のツールが動作しなくなる可能性があります。回帰を確認した場合は、Issueを作成してください。
MIT — LICENSE を参照してください。
Get the official Bank of Russia exchange rate for a single currency on a given date (or the latest published date if 'on_date' is omitted). Returns nominal, value, per-unit rate and effective quote date.
| Name | Required | Description | Default |
|---|---|---|---|
| on_date | No | ||
| char_code | Yes |
| Name | Required | Description |
|---|---|---|
| date | Yes | Effective quote date as published by CBR. |
| name | Yes | Russian-language currency name from CBR. |
| value | Yes | Rate of <nominal> units in RUB. |
| source | No | |
| nominal | Yes | Number of foreign units the rate is given for. |
| num_code | Yes | Numeric ISO 4217 code as string, e.g. '840'. |
| char_code | Yes | ISO-letter code, e.g. 'USD'. |
| vunit_rate | Yes | Rate per single unit (value / nominal). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the behavioral burden. It indicates a read operation and lists returned fields, but does not disclose authentication needs, rate limits, error handling, or side effects. Adequate but minimal.
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 a single, well-structured sentence that conveys purpose, parameter usage, and return value in a compact form. 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?
The tool has an output schema, so return details are covered externally. The description provides essential context for a simple read operation. Slight deduction for not mentioning any constraints or error conditions.
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% coverage (no descriptions for parameters). The description adds meaning: char_code is implied as the currency code, and on_date is explained as an optional date with fallback behavior. This compensates well 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 the official Bank of Russia exchange rate for a single currency on a given date, with fallback to latest date. It specifies returned fields (nominal, value, per-unit rate, effective quote date). Although sibling tools are present, the description is specific enough to distinguish usage.
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 when to use the tool (single currency, optional date) but does not provide explicit guidance on when not to use it or compare to sibling tools like history_rates or key_rate. Usage is implied but lacks alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the official CBR exchange-rate series for a single currency between two dates inclusive. Range capped at 366 days; for longer windows call repeatedly.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | Yes | ||
| char_code | Yes | ||
| date_from | Yes |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| points | Yes | |
| source | No | |
| date_to | Yes | |
| nominal | Yes | |
| char_code | Yes | |
| date_from | 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 date range limit and the need for repeated calls for longer ranges. However, it does not describe the return format (though an output schema exists), potential errors, or whether the data is read-only. The mutation status is implied as read because it is a GET-like operation.
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 sentences, front-loading the purpose and then immediately adding the critical constraint. Every word serves a purpose, no redundancy or fluff.
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 3 required parameters, no parameter descriptions, no annotations, and an output schema exists but is not referenced. The description covers the core purpose and a key limitation, but omits parameter semantics and return value context. It is adequate but feels incomplete for a new user.
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 description coverage is 0%, so the description must compensate. It only mentions 'single currency', hinting that char_code is a currency code, but provides no format or examples. It offers no additional meaning for date_from and date_to beyond what schema names imply (start and end dates).
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 states exactly what the tool does with a specific verb ('Get'), resource ('exchange-rate series'), and scope ('official CBR', 'single currency', 'between two dates inclusive'). It clearly distinguishes from siblings like 'get_rate' (likely for a single rate) by emphasizing a series of rates over a date range.
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 explicitly mentions the 366-day cap and instructs to call repeatedly for longer windows. This provides clear when-to-use and when-not-to-use guidance. However, it does not explicitly mention alternatives or compare to sibling tools, such as suggesting 'get_rate' for a single day.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get monthly year-over-year consumer price index (CPI) inflation as published by CBR for the given year range (defaults to the previous and current year).
| Name | Required | Description | Default |
|---|---|---|---|
| year_to | No | ||
| year_from | No |
| Name | Required | Description |
|---|---|---|
| note | No | Optional caveat (for example, when data is bundled rather than live-fetched). |
| points | Yes | |
| source | No | |
| year_to | Yes | |
| year_from | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions data source and time range behavior but does not disclose any limitations, rate limits, or response details. Adequate for a simple retrieval.
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?
Single sentence of 22 words, front-loaded with action, 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 presence of output schema and simple parameters, the description covers source, metric, time range defaults. Could mention return format but not required with output schema.
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% and parameters are not individually described, but the description implies year_from and year_to define the range with defaults. Adds meaning beyond schema names.
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 the verb 'Get', the resource 'monthly year-over-year CPI inflation', the source 'CBR', and the time range. Distinct from sibling tools like get_rate or key_rate.
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?
Specifies the use case (year range, defaults to previous and current year). Does not explicitly exclude other scenarios or mention alternatives, but context implies use for inflation data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the CBR key-rate (ставка рефинансирования) time series for the requested range. Defaults to the most recent 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | No | ||
| date_from | No |
| Name | Required | Description |
|---|---|---|
| points | Yes | |
| source | No | |
| date_to | Yes | |
| date_from | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It implies a read operation ('Get') and time series data, but lacks details on data freshness, time zone, pagination, or whether the operation is safe. The description is not misleading but is minimal.
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?
Two sentences, no redundant information. Front-loaded with the main action and defaults. Every word adds value.
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?
With an output schema present, return values are covered. The description explains the resource (CBR key-rate time series) and default range, but omits time zone, frequency, and any edge cases. Adequate for a simple tool but not 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 description coverage is 0%, so the description must compensate. It explains that parameters define the 'requested range' and notes a default of 30 days, adding some meaning beyond the schema. However, it does not clarify date format, optionality, or parameter semantics beyond this.
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 verb 'Get', the resource 'CBR key-rate time series', and the scope 'for the requested range' with a default of 'most recent 30 days'. This specificity distinguishes it from sibling tools like 'get_rate' (likely a single value) and 'history_rates' (broader).
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?
No explicit guidance on when to use this tool versus alternatives like 'get_rate' or 'inflation'. The description only states default behavior (30 days) but does not specify prerequisites, scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a compact macro snapshot: latest key rate, USD/EUR/CNY rates, latest YoY inflation, and the period the inflation refers to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| source | No | |
| cny_rate | No | |
| eur_rate | No | |
| usd_rate | No | |
| key_rate_pct | No | |
| inflation_period | No | ISO 'YYYY-MM' string of the inflation observation included in the snapshot. |
| inflation_yoy_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses what data is returned, but not behavioral traits like freshness, rate limits, or error handling. For a simple read tool, this is acceptable but not thorough.
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?
Single sentence that is direct and informative. No unnecessary words or repetition.
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 a presumably descriptive output schema, the description covers the key output items. However, it could mention the structure or format briefly, but not required.
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?
Input schema is empty (0 parameters), so schema coverage is 100%. Baseline for 0 parameters is 4. Description adds no parameter info but focuses on output, 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 provides a 'compact macro snapshot' listing specific indicators (key rate, USD/EUR/CNY rates, YoY inflation, period). It distinguishes from siblings like 'get_rate' (singular) or 'inflation' (singular) by being a composite.
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?
No explicit guidance on when to use this tool versus alternatives, e.g., for a broader overview vs. specific indicators. Usage is implied by the composite nature, but lacks when-not or alternative names.
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.
v0.1.0get_ratehistory_ratesinflationkey_ratestatisticsScored across 5 tools
Each tool has a distinct purpose: getting a single rate, a historical series, inflation data, key rate, or a macro snapshot. There is no overlap or ambiguity.
Names use consistent snake_case and are clear, but not all follow verb_noun pattern (e.g., 'history_rates' and 'inflation' are nouns). Minor deviation but predictable.
Five tools appropriately cover the domain of Russian exchange rates and economic statistics without being too few or too many.
The tool set covers core operations: single rate, historical series, inflation, key rate, and a macro snapshot. No obvious gaps for its stated purpose.
Public Data Ukraine Mcp connects AI agents to real public APIs via MCP. Tools include
Live & historical FX rates and currency conversion for AI agents. No API keys.
Live & historical FX rates and currency conversion for AI agents. No API keys.
Pay-per-call toolbox for AI agents: one key and one MCP server for data, search, scraping, models