Skip to main content
Glama

Динамика курса валюты ЦБ РФ

cbr_rate_history
Read-only

Fetch Bank of Russia exchange rates for a currency over a date range, including daily values and summary stats: min, max, start, end, and percent change.

Instructions

Курс валюты ЦБ РФ за период по дням и сводка: минимум, максимум, на начало и конец, изменение в процентах. По умолчанию последние 30 дней. Только чтение, без токена.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoКонец периода, ГГГГ-ММ-ДД (по умолчанию сегодня)
codeYesКод валюты ISO, например USD
fromNoНачало периода, ГГГГ-ММ-ДД (по умолчанию 30 дней назад)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'без токена' (no token/auth required), which is useful context beyond the annotations, but says nothing about pagination, rate limits, or what happens with invalid currency codes.

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 short sentences, front-loaded with the core promise (daily rates + summary) and the default window. Little waste, though the summary enumeration is slightly list-like.

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?

No output schema exists, so the description carries the return-value burden; it helpfully enumerates the summary fields (min, max, start/end, percent change). Combined with read-only annotations and full schema coverage, this is close to sufficient, though it omits error/edge-case behavior.

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 description coverage is 100%, so code/from/to are already fully documented in the schema, including their defaults. The description only restates the default 30-day window and adds no constraints or format details beyond the 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?

States a specific verb+resource: the CBR currency rate over a period by day plus a summary (min, max, start/end, percent change). It is clear what it does, but it never distinguishes itself from the sibling cbr_rates, so an agent must guess which tool returns history versus the current rate.

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

Usage Guidelines2/5

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

Provides no when-to-use or when-not-to-use guidance and names no alternative. The default ('последние 30 дней') hints at its purpose but does not help the agent choose between cbr_rate_history, cbr_rates, and cbr_key_rate.

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