MCP-сервер, который даёт Claude, Cursor и другим ИИ-ассистентам официальные данные для работы с российским бизнесом — без регистрации и токенов: проверка контрагента по ИНН в ЕГРЮЛ/ЕГРИП ФНС, курсы валют и ключевая ставка ЦБ РФ, расчёт пеней по ст. 395 ГК, производственный календарь и сроки в рабочих днях, реквизиты банка по БИК.
Спросите ассистента: «Проверь контрагента 7707083893 — можно ли с ним работать?», «Сколько пеней набежало на долг 250 000 ₽ с 1 марта?», «Пересчитай инвойс на 12 400 юаней по курсу ЦБ на дату отгрузки», «Какой срок оплаты, если 10 рабочих дней с 28 апреля?» — и он сам вызовет нужные инструменты.
Инструмент | Что делает | Источник |
| Организация или ИП по ИНН/ОГРН: название, КПП, дата регистрации и возраст, статус, руководитель, регион, недостоверность, ссылка на выписку PDF | ЕГРЮЛ/ЕГРИП ФНС |
| Контрольные суммы ИНН, ОГРН/ОГРНИП, формат БИК, ключ расчётного счёта (офлайн) | — |
| Банк по БИК: название, корсчёт, адрес | справочник БИК ЦБ |
| Официальные курсы валют на дату | ЦБ РФ |
| Динамика курса за период: минимум, максимум, изменение | ЦБ РФ |
| Пересчёт суммы по курсу ЦБ на дату | ЦБ РФ |
| Ключевая ставка: текущая и история изменений | ЦБ РФ |
| Проценты по ст. 395 ГК или пени 1/300, 1/150 с учётом смены ставки | ЦБ РФ |
| Производственный календарь: рабочие дни, праздники, переносы, норма часов | isdayoff.ru |
| Прибавить N рабочих дней к дате или посчитать рабочие дни между датами | isdayoff.ru |
Related MCP server: cbr-mcp
Нужен только Node.js 18+ — сервер запускается прямо с GitHub через npx.
claude_desktop_config.json (Настройки → Разработчик → Изменить конфиг):
{
"mcpServers": {
"ru-business": {
"command": "npx",
"args": ["-y", "github:penmadebykisss/ru-business-mcp"]
}
}
}claude mcp add ru-business -- npx -y github:penmadebykisss/ru-business-mcpЛюбой клиент с поддержкой MCP по stdio: команда npx, аргументы -y github:penmadebykisss/ru-business-mcp.
Поиск компаний по названию ФНС для внешних запросов не отдаёт — нужен ИНН или ОГРН.
При частых запросах ФНС может попросить капчу; сервер кэширует ответы на час.
Календарь на следующий год появляется после постановления Правительства о переносах выходных.
Расчёт пеней — справочный и не заменяет юридическую консультацию.
rf-marketplaces-mcp — аналитика товаров Wildberries для ИИ-агентов.
ru-business-mcp gives AI assistants official Russian business data with no account or API token: company lookup by INN/OGRN in the Federal Tax Service registry (EGRUL/EGRIP), Bank of Russia exchange rates and key rate, late-payment interest (Civil Code art. 395), the Russian production calendar and business-day math, and bank details by BIK.
npx -y github:penmadebykisss/ru-business-mcpMIT
Реквизиты банка по БИК: полное и краткое название, корреспондентский счёт, город, адрес, регистрационный номер ЦБ. Нужен для заполнения платёжек и договоров. Данные справочника bik-info.ru (по базе ЦБ РФ). Только чтение, без токена.
| Name | Required | Description | Default |
|---|---|---|---|
| bik | Yes | БИК — 9 цифр |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and open-world behavior, and the description adds useful context beyond them: no token required and data sourced from bik-info.ru based on the CBR RF database. It does not cover rate limits, error handling, or response format details.
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 three compact sentences with the core purpose front-loaded, followed by use case, source, and access constraints. Every sentence contributes useful information without redundancy.
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?
For a simple read-only lookup, the definition is complete: the schema fully documents the only parameter, annotations cover safety, and the description enumerates the returned bank fields and data source. No output schema is needed, and the description compensates by listing key return values.
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 100%, with the single BIK parameter already documented in the schema as a 9-digit string. The description repeats the lookup key but adds no further syntax or semantic detail, so the baseline 3 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 resource and lookup key: bank details by BIK, including full/short name, correspondent account, city, address, and CBR registration number. It distinguishes the tool's output scope well, but does not explicitly contrast it with siblings such as validate_requisites or company_check.
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?
It gives a concrete use context: needed for filling payment orders and contracts. No when-not-to-use guidance or named alternatives are provided, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ключевая ставка Банка России: текущее значение, дата последнего изменения и история изменений за период (по умолчанию 2 года). Пригодится для расчёта пеней, процентов по ст. 395 ГК и оценки стоимости денег. Только чтение, без токена.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Конец периода (по умолчанию сегодня) | |
| from | No | Начало периода (по умолчанию 2 года назад) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the 'Только чтение' clause is largely duplicative. It does add one useful non-annotation fact ('без токена' – no auth token required), but does not disclose pagination, rate limits, or error behavior on malformed dates.
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?
Three compact sentences, front-loaded with the resource and returned fields, followed by use cases and an operational note. Every sentence is short and earns its place, though the use-case clause is the weakest link.
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?
There is no output schema, so the description correctly takes on the return-value burden by naming current value, last-change date, and history. Both optional params and the read-only/no-token profile are covered, leaving only sibling disambiguation and edge-case handling unaddressed.
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 100%, with both 'from'/'to' documented, including their defaults, so the schema already carries the semantics. The description restates the default 2-year period but adds no format or boundary guidance beyond what the schema provides – baseline 3.
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?
States a specific resource (Банка России ключевая ставка) and precisely what it returns: current value, last-change date, and period history. The purpose is unambiguous. However, it fails to differentiate from the sibling cbr_rate_history, which it likely overlaps with since it also returns history for a period.
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?
It gives scenario context ('пригодится для расчёта пеней, процентов по ст. 395 ГК и оценки стоимости денег'), which implies when to reach for it. But it never names the alternative siblings (cbr_rate_history, cbr_rates, late_payment_penalty) or states when this tool is the wrong choice, leaving the routing ambiguity unresolved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Курс валюты ЦБ РФ за период по дням и сводка: минимум, максимум, на начало и конец, изменение в процентах. По умолчанию последние 30 дней. Только чтение, без токена.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Конец периода, ГГГГ-ММ-ДД (по умолчанию сегодня) | |
| code | Yes | Код валюты ISO, например USD | |
| from | No | Начало периода, ГГГГ-ММ-ДД (по умолчанию 30 дней назад) |
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.
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.
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.
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.
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.
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.
Официальные курсы ЦБ РФ на дату (по умолчанию на сегодня): рублей за единицу валюты и за номинал. Можно ограничить списком кодов (USD, EUR, CNY…). Если на дату курс не устанавливался (выходной), ЦБ отдаёт последний действующий — поле date показывает, на какую дату он установлен. Только чтение, без токена.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Дата курса ГГГГ-ММ-ДД; по умолчанию сегодня | |
| codes | No | Коды валют ISO, например ["USD","EUR","CNY"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered, and the description's 'Только чтение, без токена' merely corroborates it. The real added value is disclosing the holiday fallback: if no rate was set, the Central Bank returns the last effective one and the date field reveals which date it belongs to — a non-obvious trait not present in the structured data.
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?
Dense but efficient: purpose, default, filter, and fallback behavior are front-loaded with no filler. It is a single packed paragraph rather than cleanly segmented points, which slightly hurts scanability but not content economy.
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 no output schema, the description compensates by describing the return shape (rubles per unit and per nominal, date field indicating effective date) and the fallback semantics. Both optional params are understood, so an agent has enough to call it correctly, though explicit sibling routing would complete the picture.
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 100%, so both parameters (date format, ISO codes with example) are already fully documented in the schema, making 3 the baseline. The description reinforces the codes filter and date default but adds no syntax or format detail beyond what the schema states.
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?
States a specific verb and resource ('Официальные курсы ЦБ РФ на дату') and pins the exact output semantic — rubles per unit of currency and per nominal. This is clearly a single-date rate lookup, distinguishable from siblings like cbr_rate_history (time series) and currency_convert (conversion) without opening either schema.
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?
Implies usage through defaults ('по умолчанию на сегодня') and the optional code filter, which tells an agent how to scope the call. However, it never names alternatives or when-not-to-use conditions — e.g. that cbr_rate_history should be preferred for ranges — so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Сведения из ЕГРЮЛ/ЕГРИП ФНС по ИНН или ОГРН организации или ИП: полное и краткое название, ИНН, ОГРН, КПП, дата регистрации и возраст компании, статус (действует или деятельность прекращена), руководитель, регион, отметка о недостоверности сведений и ссылка на официальную выписку PDF. Используйте перед сделкой, для заполнения реквизитов договора или счёта. Номер предварительно проверяется по контрольной сумме. Поиск по названию ФНС для внешних запросов не поддерживает — нужен ИНН или ОГРН. Только чтение, без токена.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ИНН (10 или 12 цифр) или ОГРН/ОГРНИП (13 или 15 цифр) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations it adds auth context ('без токена' = no token needed) and a validation behavior (the number is checksum-verified before use). 'Только чтение' merely restates the annotation, but the auth and checksum notes are genuine additions.
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?
Purpose is front-loaded, followed by usage, constraint, and behavioral notes in a logical order. The long output-field enumeration is dense but earns its place because no output schema exists to carry that information.
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 no output schema, the description compensates by enumerating the returned fields, and it also covers the single parameter, the auth model, and input constraints. Nothing an agent needs to call it correctly appears to be missing.
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 100%, so the baseline is 3, but the description adds meaning the schema lacks: the id is pre-validated by checksum and only INN/OGRN forms (never a name) are accepted. This is a modest but real semantic addition.
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 names a specific resource (ЕГРЮЛ/ЕГРИП ФНС data via INN/OGRN) and enumerates exactly what is returned (name, INN, OGRN, KPP, status, head, region, PDF extract). The purpose is unmistakable, but it never distinguishes itself from the sibling validate_requisites, so it falls short of a 5.
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?
It gives concrete usage contexts (before a transaction, to fill contract or invoice requisites) and a hard constraint (name search is unsupported, an INN or OGRN is required). No alternative sibling tool is named, so it stops short of explicit when-not/alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Пересчитывает сумму между рублём и любой валютой ЦБ (или между двумя валютами через рубль) по официальному курсу на дату — например, для счёта, инвойса или отчёта. Только чтение, без токена.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Целевая валюта | |
| date | No | Дата курса ГГГГ-ММ-ДД; по умолчанию сегодня | |
| from | Yes | Исходная валюта (RUB, USD, EUR, CNY…) | |
| amount | Yes | Сумма |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety bar is lower; the description still adds value by stating 'без токена' (no token needed), which is auth context not present in annotations, plus that the rate is the official CBR rate and the date defaults to today. It does not describe pagination or return format, but for a read-only tool that is minor.
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 tight sentences, front-loaded with the conversion verb and scope, then the mechanism, then use cases, then the read-only/auth note. No wasted 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?
For a simple conversion tool with fully documented parameters and readOnly/openWorld annotations, the description covers purpose, mechanism, and auth adequately. It omits what the response contains (converted amount, rate applied), but with no output schema this is a modest gap.
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 100%, so all four parameters (amount, from, to, date) are already documented in the schema; the description adds the mechanism ('via ruble') and the official-rate-on-date semantics but no syntax or format detail beyond the schema. Baseline 3 applies when the schema carries the load.
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?
States a specific verb (пересчитывает/converts) plus resource (amount between ruble and any CBR currency, or cross-currency via ruble) at the official rate on a date. It implicitly separates itself from rate-listing siblings like cbr_rates and cbr_rate_history by being a conversion tool, but never names an alternative explicitly.
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?
Provides use-case examples (invoice, report) that imply when it fits, and clarifies the conversion paths (RUB↔currency or currency↔currency via RUB). However, it gives no when-not guidance and does not route the agent away from siblings such as cbr_rates or cbr_rate_history, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Считает неустойку за просрочку оплаты по ключевой ставке ЦБ с учётом всех её изменений за период: проценты по ст. 395 ГК РФ (ставка/365 или 366 в день) или пени по доле ставки (например 1/300 для коммунальных и налоговых пеней физлиц, 1/150 для организаций после 30 дней). Даёт итог и разбивку по периодам ставки. Не заменяет юриста.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Дата оплаты или расчёта включительно (по умолчанию сегодня) | |
| from | Yes | Первый день просрочки | |
| amount | Yes | Сумма долга в рублях | |
| method | No | art395 — проценты по ст. 395 ГК; fraction — доля ставки в день | art395 |
| fraction | No | Знаменатель доли для method=fraction, например 300 или 150 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=true, the annotations already establish that this is a safe, external-data-reading operation. The description adds useful behavioral context beyond the annotations: it specifies the output includes a total and a breakdown by rate periods, and it includes a legal disclaimer that it does not replace a lawyer.
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 front-loaded with the core purpose and remains appropriately sized for a specialized legal-financial calculator. The legal disclaimer earns its place in this domain, and there is little redundant phrasing.
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?
Even though there is no output schema, the description states the key return shape (total and breakdown by rate periods). It covers the calculation methods and legal caveat, and the schema handles parameter details. Minor gaps such as rounding or data-source specifics do not prevent correct invocation.
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 100%, so the baseline is 3. The description adds domain meaning beyond the schema by giving concrete examples of fraction denominators (1/300 for certain utility and tax penalties, 1/150 for organizations after 30 days) and by clarifying the legal basis behind the method choices.
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 names a specific verb and resource: calculating late-payment penalties using the Central Bank key rate, with two distinct legal methods (Article 395 interest and fraction-based penalties). This is clearly distinguishable from sibling rate-history and conversion tools, even without naming them explicitly.
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 the legal contexts for the two methods, which implies when each applies, but it does not explicitly state when to use this tool versus alternatives such as cbr_key_rate or cbr_rate_history. Usage is inferable from the stated purpose rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Офлайн-проверка контрольных сумм ИНН (10 и 12 цифр), ОГРН (13) и ОГРНИП (15), а также формата БИК (9 цифр) и расчётного счёта против БИК. Помогает быстро поймать опечатку в реквизитах до запроса в ФНС или отправки платежа. Не обращается к сети; чтобы узнать, существует ли компания, используйте company_check.
| Name | Required | Description | Default |
|---|---|---|---|
| bik | No | БИК банка | |
| inn | No | ИНН | |
| ogrn | No | ОГРН или ОГРНИП | |
| account | No | Расчётный счёт (20 цифр); проверяется вместе с БИК |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'Не обращается к сети' statement positively reinforces the openWorldHint=false annotation and tells the agent this is a purely offline syntactic check, which is meaningful context. It does not cover what the result looks like when a checksum fails, so it falls just short of fully rich disclosure.
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?
Three compact sentences, each earning its place: what is validated, why it matters, and the boundary/alternative. The scope is front-loaded before the routing hint.
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?
For a read-only, no-network validation tool with no output schema, the description covers scope, offline behavior, and the sibling alternative. It stops short of describing the validation outcome/message format, which is the only remaining gap an agent might want.
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 100%, so the baseline is 3, but the description adds genuine value beyond the terse schema labels: digit-count constraints (10/12, 13, 15, 9, 20) and the cross-field rule that the account is validated together with БИК. That extra semantics lifts it above the baseline.
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?
States a specific verb (офлайн-проверка контрольных сумм) and enumerates exactly which resources are validated (ИНН, ОГРН, ОГРНИП, БИК, расчётный счёт) with their digit lengths. It also distinguishes itself from company_check, which the agent would otherwise conflate with this tool.
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?
Explicitly frames the use case ('поймать опечатку в реквизитах до запроса в ФНС или отправки платежа') and names the alternative with the condition that selects it ('чтобы узнать, существует ли компания, используйте company_check'). Nothing about when-to-use is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Производственный календарь России на год или месяц: число рабочих, выходных и праздничных дней, сокращённые предпраздничные дни, норма часов при 40-часовой неделе, список нерабочих дней вне обычных выходных и рабочих суббот (переносы). Для расчёта зарплаты, отпускных, сроков и графиков. Только чтение, без токена.
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | Год | |
| month | No | Месяц 1–12; без него — весь год по месяцам |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that no token/auth is required, which is genuinely new information, but it does not disclose pagination, return shape, or the fact that range is bounded (2013-2030) — that constraint lives only in the schema.
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, front-loaded with the resource and the returned data, with no filler. The enumeration is dense but each clause carries information, and the read-only/no-token note is appropriately placed last.
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 only two parameters, no output schema, and full schema coverage, the description is nearly complete: it enumerates the returned content so the missing output schema is largely compensated. Minor gaps remain around the supported year range and the year-vs-month return distinction, though both are recoverable from the 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 description coverage is 100%, so the schema already documents both parameters, including that omitting month returns the whole year by month. The description restates the year/month scope without adding syntax, format, or edge-case detail beyond the schema; baseline 3 applies.
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?
States a specific resource and scope (Russian production calendar for a year or month) plus the exact data it returns: working/weekend/holiday day counts, shortened pre-holiday days, 40-hour-week hour norms, and transfer days. An agent can tell what it gets. It does not, however, distinguish itself from the sibling work_days_calc, which appears to overlap in purpose.
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?
Usage is implied through the intended scenarios (payroll, vacation pay, deadlines, schedules), which gives an agent a reasonable sense of when to reach for it. There is no explicit when-not guidance and no mention of the alternative work_days_calc, so selection between the two siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Две операции по производственному календарю РФ: add — к дате прибавить N рабочих дней (срок оплаты, поставки, ответа на претензию; отрицательное N — назад); between — сколько рабочих дней между двумя датами включительно. Учитывает праздники и переносы; календарь на следующий год появляется после постановления Правительства о переносах. Только чтение, без токена.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Для between: конечная дата | |
| date | Yes | Начальная дата | |
| days | No | Для add: сколько рабочих дней прибавить (начальный день не считается) | |
| operation | Yes | add — прибавить рабочие дни к дате; between — посчитать рабочие дни между датами |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: 'Только чтение, без токена' confirms the read-safe profile and adds an auth fact (no token needed) that readOnlyHint alone does not convey, and the note that next year's calendar only appears after the Government decree discloses a genuine data-availability limitation. The read-only phrase is somewhat redundant with readOnlyHint, keeping it from a 5.
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 two operations are front-loaded and each clause carries information: operation split, examples, negative-N direction, inclusive counting, holiday/transfer handling and calendar-availability caveat — with no filler sentences.
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?
For a simple two-operation calculator with no output schema, it covers operations, domain, directionality, inclusivity, calendar limitations and the no-token fact. It never states what each operation returns (a date vs. a day count) or out-of-range/invalid-date behavior, which is the remaining gap given the absence of an 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 100% (baseline 3), but the description still adds meaning the schema lacks: negative N moves backward, and `between` counts days 'включительно' (inclusive) — an inclusive/exclusive decision not stated in the schema.
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?
Names both operations concretely (add / between) with their exact semantics, resource (RF production calendar) and example contexts (payment, delivery, claim deadlines). Very clear what it does, but it never distinguishes itself from the overlapping sibling work_calendar, which is the main thing an agent must disambiguate.
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?
Gives concrete use cases for `add` (срок оплаты, поставки, ответа на претензию) and clarifies the negative-N direction, which tells the agent when the tool applies. It stops short of any exclusion or explicit alternative (e.g. when to prefer work_calendar or late_payment_penalty instead), so no 'when-not' guidance.
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.
v1.0.0cbr_rates1 field changedInput schema / properties / date / descriptionPrevious value: -"Дата в формате ГГГГ-ММ-ДД"New value: +"Дата курса ГГГГ-ММ-ДД; по умолчанию сегодня"currency_convert1 field changedInput schema / properties / date / descriptionPrevious value: -"Дата в формате ГГГГ-ММ-ДД"New value: +"Дата курса ГГГГ-ММ-ДД; по умолчанию сегодня"work_days_calc1 field changedInput schema / properties / operation / descriptionAdded value: +"add — прибавить рабочие дни к дате; between — посчитать рабочие дни между датами"v0.1.0bank_by_bikcbr_key_ratecbr_rate_historycbr_ratescompany_checkcurrency_convertlate_payment_penaltyvalidate_requisiteswork_calendarwork_days_calcScored across 10 tools
Each tool has a distinct resource and operation: bank details by BIK, currency conversion, CBR rates, key rate, penalty calculation, work calendars, company lookup, and requisites validation. Overlaps are explicitly clarified in descriptions (e.g. cbr_rates vs cbr_rate_history, company_check vs validate_requisites).
All names use consistent snake_case, which is highly readable and predictable. However, patterns mix noun-only, noun_verb, verb_noun, and prefix-based forms (cbr_*, work_*), so they are not perfectly uniform.
Ten tools is well-scoped for a Russian business reference/calculator server. Each tool earns its place and no obvious redundancy or padding is present.
The surface covers core Russian business needs: banking, currency, key rate, penalties, work calendar, company checks, and requisites validation. Minor gaps remain, such as tax rates/VAT lookups or company search by name, but these are not fatal for the stated reference/calculator purpose.
Russian company lookup (EGRUL/INN), Cyrillic search, RU page to Markdown. Pay per call in USDC.
RU INN/OGRN, banks, geo, WHOIS. Agent self-registers via register_agent. 20 free/day.
Official public & government APIs, dozens of countries: registers, statistics, open data. Keyless.
Colombian company and public-procurement data by NIT: RUES commercial registry, SECOP contracts, Supersociedades financials, sanctions and OFAC/UN lists, each field with its official source URL and capture date. No key needed to connect or for radicadouno_comprobar (free, 10/day). Buy a signed report per company (89,900 COP) or a Business key from within the server: no human in the loop. Companies only: no natural persons (Law 1581/2012). Not a credit score.
