AI 에이전트에게 러시아 중앙은행(Центральный банк РФ, CBR)의 공개 데이터(환율, 기준 금리, 인플레이션 및 거시 경제 스냅샷)를 제공하는 MCP(Model Context Protocol) 서버입니다.
mcp-cbr-rates는 러시아 핀테크 생태계에 중점을 둔 atomno MCP 서버 제품군의 일부입니다. 완전한 오픈 소스이며, API 키가 필요 없고, 공식 CBR 공개 엔드포인트를 기반으로 구축되었습니다.
5개의 고품질 MCP 도구 (각 도구는 엄격한 Pydantic 스키마를 따름): 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 스키마가 변경될 경우, 이 패키지가 업데이트될 때까지 개별 도구가 작동하지 않을 수 있습니다. 회귀 문제가 발생하면 이슈를 제기해 주시기 바랍니다.
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