一个模型上下文协议 (MCP) 服务器，向 AI 代理公开俄罗斯中央银行 (Центральный банк РФ, CBR) 的数据 — 包括货币报价、基准利率、通胀率以及简要的宏观快照。
mcp-cbr-rates 是 atomno 系列 MCP 服务器的一部分，专注于俄罗斯金融科技生态系统。它完全开源，无需 API 密钥，并基于官方公开的 CBR 端点构建。
五个高质量的 MCP 工具，每个都具有严格的 Pydantic 模式：
get_rate、history_rates、key_rate、inflation、statistics。
内置 TTL (生存时间) 缓存：每日报价缓存 1 小时，历史序列缓存 24 小时，以减轻对源服务器的压力。
异步 httpx 传输，在遇到 5xx 错误时自动重试。
通过 defusedxml 进行安全的 XML 解析。
50 多个单元测试，使用 respx 模拟 HTTP，覆盖率 ≥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 日的官方欧元汇率是多少？” 工具：
get_rate(char_code="EUR", on_date="2024-04-25")
“绘制过去 90 天的美元兑卢布日汇率图表。” 工具：
history_rates(char_code="USD", date_from=..., date_to=...)
“一次性获取最新的基准利率、美元/欧元/人民币汇率和通胀率。” 工具：
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