MCP-сервер, с которым Claude, Cursor и другие ИИ-ассистенты считают зарплату по правилам 2025–2026 годов: сумму на руки и обратно, НДФЛ по прогрессивной шкале 13–22 % нарастающим итогом, страховые взносы работодателя (общий тариф, льготы МСП и IT), полную стоимость сотрудника, отпускные, больничные и компенсацию за неиспользованный отпуск. Всё считается локально, без токенов и отправки данных.
Спросите ассистента:
«Кандидат хочет 150 000 на руки — какой оклад ставить и во сколько он обойдётся компании?»
«Сколько я получу на руки при зарплате 400 000, и с какого месяца налог станет 15 %?»
«Посчитай отпускные: заработок за год 1,2 млн, отпуск 14 дней»
«Больничный 10 дней, стаж 6 лет, заработок 1 млн и 800 тыс. за два прошлых года»
Инструмент | Что делает |
| По окладу: НДФЛ, на руки, взносы и стоимость сотрудника помесячно за год, с премией |
| Какой оклад начислить, чтобы на руки была нужная сумма |
| НДФЛ с годового дохода или с отдельной выплаты, разбивка по ступеням и эффективная ставка |
| Отпускные по среднему дневному заработку (29,3 дня) |
| Компенсация при увольнении, в том числе расчёт положенных дней |
| Больничный: средний заработок с лимитами, % по стажу, доля работодателя и Соцфонда |
| МРОТ, предельная база, шкала НДФЛ, тарифы, лимиты больничных на год |
Параметры 2026 года: МРОТ 27 093 ₽, предельная база взносов 2 979 000 ₽ (30 % до неё, 15,1 % сверх), НДФЛ 13 % до 2,4 млн, 15 % до 5 млн, 18 % до 20 млн, 20 % до 50 млн, 22 % сверх; максимальный средний дневной заработок для больничного — 6 827,40 ₽. Льгота МСП 15 % с части зарплаты свыше 1,5 МРОТ с 2026 года действует только для отраслей из перечня Правительства.
Related MCP server: taiwan-payroll
Нужен Node.js 18+.
{
"mcpServers": {
"ru-payroll": {
"command": "npx",
"args": ["-y", "github:penmadebykisss/ru-payroll-mcp"]
}
}
}claude mcp add ru-payroll -- npx -y github:penmadebykisss/ru-payroll-mcpНе учитываются стандартные вычеты (на детей и др.), районные коэффициенты и северные надбавки — включайте их в сумму начислений сами.
Больничный по уходу за ребёнком, декретные и пособия по беременности считаются по другим правилам и здесь не поддерживаются.
Результаты справочные: в учётной программе итог может отличаться на копейки из-за округлений.
npm test # эталонные значения посчитаны вручную по НК РФ, 255-ФЗ и Положению № 922ru-payroll-mcp is a Russian payroll calculator for AI assistants (2025–2026 rules): net ↔ gross salary with the progressive 13–22 % personal income tax applied year-to-date, employer insurance contributions (general, SME and IT tariffs), total employee cost, vacation pay, sick pay and unused-vacation compensation. Fully local, no API keys.
npx -y github:penmadebykisss/ru-payroll-mcpru-docs-mcp — счета, акты и QR-оплата в PDF
ru-business-mcp — проверка контрагентов, курсы ЦБ, производственный календарь
MIT
НДФЛ резидента с дохода от работы по шкале 2025–2026 годов: 13 % до 2,4 млн, 15 % до 5 млн, 18 % до 20 млн, 20 % до 50 млн, 22 % сверх (в год). Считает налог с годового дохода с разбивкой по ступеням и эффективной ставкой, либо с отдельной выплаты с учётом дохода с начала года (income_before). Для зарплаты целиком удобнее salary_calc. Не учитывает вычеты и доходы с другой шкалой (дивиденды, вклады, продажа имущества). Только вычисление.
| Name | Required | Description | Default |
|---|---|---|---|
| income | Yes | Доход, ₽: годовой или сумма одной выплаты, если задан income_before | |
| income_before | No | Доход с начала года до этой выплаты, ₽ — тогда считается налог только с income |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description still adds value by clarifying scope boundaries: it is 'только вычисление' and explicitly does not model deductions or alternative tax scales. It stops short of richer notes (e.g. rounding behavior), so not 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?
Front-loaded with the core purpose and rate table, then the call modes, then sibling routing, then exclusions. Every clause earns its place; no filler despite the longer length.
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, yet the description explains what is returned (bracket-by-bracket breakdown and effective rate), and the two input modes are fully disambiguated. Nothing needed to invoke it correctly is 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%, with both income and income_before fully documented, so the baseline is 3. The description echoes income_before semantics (tax computed on the single payment given prior-year-to-date income) but adds no syntax or edge-case detail 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 precise verb+resource (calculates NDFL for a resident on work income under the 2025–2026 progressive scale) and even enumerates the brackets. It explicitly distinguishes itself from the sibling salary_calc for full-salary calculations, so an agent can route without opening schemas.
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?
Names the alternative ('Для зарплаты целиком удобнее salary_calc') and then states explicit exclusions: no deductions and no other-scale income (dividends, deposits, property sales). When-to-use, when-to-use-something-else, and when-not-at-all are all covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Справочные параметры для зарплаты за 2025 или 2026 год: МРОТ, предельная база страховых взносов, 1,5 МРОТ для льготы МСП, шкала НДФЛ, тарифы взносов и максимальный средний дневной заработок для больничных. Используйте, чтобы ответить на вопрос о ставках или проверить исходные данные. Только чтение.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Расчётный год: 2025 или 2026 (по умолчанию текущий) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered; the closing "Только чтение" merely repeats it and earns no credit. The description does add genuinely useful behavioral context by scoping the data to the 2025/2026 reference years, but says nothing about freshness, source, or limits.
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 dense sentences plus a short tag; the content enumeration is front-loaded and earns its place. The trailing "Только чтение" is redundant given the annotations and is the only wasted token.
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 correctly compensates by enumerating the values returned, and the single parameter is fully covered by the schema. Annotations handle the safety profile, so nothing an agent needs to call this lookup tool is missing; only data freshness/latency context is absent.
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% and the single `year` parameter is fully documented in the schema, so the baseline is 3. The description corroborates the valid range ("за 2025 или 2026 год") but adds no format or behavioral detail 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?
The description names the resource (payroll reference parameters) and enumerates exactly what it returns: МРОТ, insurance contribution base limits, 1.5 МРОТ for the SME benefit, NDFL scale, contribution tariffs, and maximum average daily earnings. This implicitly separates it from the calculator siblings (salary_calc, ndfl_calc, etc.), though none of them is named 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?
"Используйте, чтобы ответить на вопрос о ставках или проверить исходные данные" gives two clear triggering scenarios: answering rate questions and verifying source data. There is no explicit when-not guidance or named alternative, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Считает по окладу (зарплате до вычета налога) помесячно за год: НДФЛ по прогрессивной шкале 13–22 % нарастающим итогом, сумму на руки, страховые взносы работодателя и полную стоимость сотрудника; можно добавить разовую премию в конкретный месяц. Возвращает first_month (на руки в первом месяце), rows по месяцам (видно, когда растёт ставка НДФЛ и когда взносы падают после предельной базы) и totals за год. Обратная задача — salary_from_net. Вычеты на детей не учитываются. Только вычисление, без сети.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Расчётный год: 2025 или 2026 (по умолчанию текущий) | |
| bonus | No | Разовая премия, ₽ | |
| gross | Yes | Начисленная зарплата в месяц до НДФЛ, ₽ (оклад плюс постоянные надбавки) | |
| months | No | Сколько месяцев считать с января | |
| tariff | No | Тариф взносов: standard — общий (30 % до предельной базы, 15,1 % сверх); msp — МСП из перечня отраслей Правительства (15 % с части свыше 1,5 МРОТ); msp_manufacturing — МСП обрабатывающих производств (7,6 % свыше 1,5 МРОТ); it — аккредитованные IT-компании (7,6 %) | standard |
| bonus_month | No | Месяц выплаты премии 1–12 (по умолчанию декабрь) | |
| accident_pct | No | Тариф взносов на травматизм, % (0,2 для офисной работы; зависит от класса риска) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: it explains the returned fields first_month, rows, totals, notes when NDFL brackets rise and when contribution caps apply, and states the child-deduction limitation. It does not cover error handling or rounding behavior, so it is strong but not exhaustive.
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 calculation, then moves to return shape, inverse sibling, limitation, and network constraint. Every sentence adds useful selection or invocation context, and there is no filler 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?
For a seven-parameter calculator with no output schema, the description is complete enough: the schema covers parameter semantics, while the description covers the calculation behavior, return fields, inverse sibling, and key limitation. Annotations already cover the safety profile, so the remaining description burden is appropriately met.
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 all seven parameters in detail, including tariff and accident_pct. The description mentions gross, bonus, and bonus timing at a high level, but it does not add syntax or format meaning beyond the schema's own parameter descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
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 a specific verb and resource: it calculates net salary and employer cost from a gross monthly salary across a year, with progressive NDFL and contribution details. It explicitly distinguishes itself from the inverse sibling by naming salary_from_net as the reverse task, so an agent can tell the two apart without opening schemas.
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 names the inverse alternative explicitly: 'Обратная задача — salary_from_net', and it states an exclusion ('Вычеты на детей не учитываются') plus the constraint that it is pure calculation with no network. This gives clear routing context for gross-to-net employee-cost calculations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Находит, какую зарплату начислять, чтобы сотрудник получил на руки нужную сумму, с учётом прогрессивного НДФЛ (если с начала года уже выплачено income_before, расчёт идёт по его ставке). Возвращает gross, ndfl, net, взносы и стоимость сотрудника в этом месяце. Используйте при найме, когда кандидат называет сумму «на руки»; прямой расчёт по окладу — salary_calc. Только вычисление, без сети.
| Name | Required | Description | Default |
|---|---|---|---|
| net | Yes | Нужная сумма на руки за месяц, ₽ | |
| year | No | Расчётный год: 2025 или 2026 (по умолчанию текущий) | |
| tariff | No | Тариф взносов: standard — общий (30 % до предельной базы, 15,1 % сверх); msp — МСП из перечня отраслей Правительства (15 % с части свыше 1,5 МРОТ); msp_manufacturing — МСП обрабатывающих производств (7,6 % свыше 1,5 МРОТ); it — аккредитованные IT-компании (7,6 %) | standard |
| accident_pct | No | Тариф взносов на травматизм, % (0,2 для офисной работы; зависит от класса риска) | |
| income_before | No | Доход сотрудника у этого работодателя с начала года до этого месяца, ₽ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotent, no open world), and the description reinforces this with 'Только вычисление, без сети' plus the progressive-NDFL behavior keyed off income_before. It also lists the returned values (gross, ndfl, net, взносы, стоимость) since no output schema exists, but says nothing about edge cases such as zero or implausibly high net.
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?
Four short sentences ordered purpose → what if income_before is set → return values → when to use / alternative / no network. No filler, and the key scoping route to salary_calc is front-loaded before the closing constraint.
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 steps in and enumerates the returned fields (gross, ndfl, net, contributions, employer cost). Combined with the alternative-tool routing and the network-free note, nothing an agent needs to invoke it correctly is 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 coverage is 100%, so baseline is 3, but the description adds a genuine semantic link the schema does not: income_before changes which progressive NDFL bracket/rate the calculation uses. That relationship is the non-obvious part of the call and is called out explicitly.
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 precise verb and resource (finds the gross salary needed to produce a given net) and explicitly names the sibling it is not: 'прямой расчёт по окладу — salary_calc'. An agent can separate it from salary_calc and ndfl_calc 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?
Gives an explicit triggering context ('Используйте при найме, когда кандидат называет сумму «на руки»') and names the alternative tool for the opposite direction of calculation. Both the when and the when-otherwise are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Пособие по временной нетрудоспособности (255-ФЗ): заработок за два предыдущих года (каждый ограничен предельной базой) / 730, но не ниже МРОТ × 24 / 730; процент по страховому стажу (до 5 лет — 60 %, 5–8 — 80 %, 8+ — 100 %); первые 3 дня оплачивает работодатель, остальные — Социальный фонд. Возвращает average_daily, per_day, employer_part, sfr_part, total, НДФЛ и на руки. Больничный по уходу за ребёнком и по беременности считаются иначе — не для них. Только вычисление.
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | Календарные дни болезни | |
| year | No | Расчётный год: 2025 или 2026 (по умолчанию текущий) | |
| earnings_prev1 | Yes | Заработок за прошлый год, ₽ (для больничного в 2026 — за 2025) | |
| earnings_prev2 | Yes | Заработок за позапрошлый год, ₽ (для 2026 — за 2024) | |
| insurance_years | Yes | Страховой стаж в годах, например 6.5 | |
| part_time_ratio | No | Доля ставки при неполном времени (для минимального пособия) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the entire calculation logic (two-year earnings capped by the base limit, /730 floor at MROT×24/730, seniority tiers, 3-day employer split) and the set of returned fields, confirming no side effects.
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?
Front-loaded with the formula and scope, then exclusions, then return values. It is a single dense paragraph but every clause carries a rule the agent needs; 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?
With no output schema, the description compensates by enumerating the returned values (average_daily, per_day, employer_part, sfr_part, total, НДФЛ, на руки) and fully specifies the computation, exclusions and scope. An agent has everything needed to call it correctly.
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 goes beyond the schema by explaining the semantics that drive the parameters: which prior years feed earnings_prev1/prev2, the seniority percentage bands for insurance_years, and the MROT floor that part_time_ratio interacts with.
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: computing the temporary-disability (sick-leave) benefit under 255-FZ, with the exact formula. "Только вычисление" makes clear it is a pure calculation, distinguishing it from payroll mutation tools among the siblings.
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 excludes two adjacent cases: "Больничный по уходу за ребёнком и по беременности считаются иначе — не для них." That is clear when-not guidance. It stops short of naming an alternative tool for those cases, but no sibling covers them, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Компенсация при увольнении: сколько дней отпуска положено (28 дней в год пропорционально отработанным месяцам, с округлением месяцев по правилу «больше половины — целый»), если дни не заданы явно, и сумма по среднему дневному заработку, НДФЛ и на руки. Средний заработок считается как в vacation_pay. Только вычисление.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Неиспользованные дни, если известны; иначе считаются из worked_months | |
| used_days | No | Уже использовано дней в этом рабочем году | |
| annual_days | No | Положено дней отпуска в год | |
| full_months | No | Сколько месяцев расчётного периода отработано полностью | |
| earnings_12m | Yes | Заработок за 12 месяцев до месяца отпуска, ₽: зарплата и премии; без больничных, отпускных и матпомощи | |
| partial_days | No | Для неполных месяцев: сумма «29,3 / дней в месяце × отработанные календарные дни» по каждому такому месяцу | |
| income_before | No | Доход с начала года до выплаты — для точной ставки НДФЛ, ₽ | |
| worked_months | No | Отработано месяцев в текущем рабочем году (для расчёта дней) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is covered; the description adds real behavioral content beyond them: the 28-days-per-year proportional accrual, the 'more than half = full month' rounding rule, and that average daily earnings are computed as in vacation_pay. It does not state rate limits or error behavior, keeping it short of 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?
A single tightly packed paragraph that front-loads the computation rules and ends with the scope limit 'Только вычисление'. The nested parentheticals make it dense but no sentence is wasted.
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 8 parameters, no output schema, and a pure-computation tool, the description names the outputs (days, sum, NDFL, net) and the derivation fallbacks, which is enough for correct invocation. It could still clarify the sibling boundary versus vacation_pay.
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 baseline is 3, but the description adds genuine meaning: 'days' is derived from worked_months when omitted, and it supplies the month-rounding rule ('больше половины — целый') that governs worked_months/full_months and is absent from the schema descriptions.
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: computes unused-vacation compensation on dismissal, returning entitled days plus amount, NDFL and net pay. It is clearly distinct from vacation_pay and salary_calc, though it never explicitly frames that contrast — it only says the average-earnings method matches vacation_pay.
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 conditions ('если дни не заданы явно' days come from worked_months) and scopes behavior with 'Только вычисление', but never says when to pick this tool over vacation_pay or salary_calc. The agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Отпускные по ст. 139 ТК и Положению № 922: средний дневной заработок = заработок за 12 месяцев / (29,3 × полные месяцы + дни неполных месяцев), умноженный на календарные дни отпуска; плюс НДФЛ и сумма на руки. Возвращает average_daily, gross, ndfl, net. Отпускные выплачиваются не позднее чем за 3 дня до отпуска. Для компенсации при увольнении — unused_vacation_compensation. Индексацию окладов в расчётном периоде учтите в earnings_12m сами. Только вычисление.
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | Календарные дни | |
| full_months | No | Сколько месяцев расчётного периода отработано полностью | |
| earnings_12m | Yes | Заработок за 12 месяцев до месяца отпуска, ₽: зарплата и премии; без больничных, отпускных и матпомощи | |
| partial_days | No | Для неполных месяцев: сумма «29,3 / дней в месяце × отработанные календарные дни» по каждому такому месяцу | |
| income_before | No | Доход с начала года до выплаты — для точной ставки НДФЛ, ₽ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered; the description reinforces this with 'Только вычисление'. It adds real behavioral context beyond annotations by naming the returned fields (average_daily, gross, ndfl, net) and the statutory payment-deadline rule, though it omits units/format for the returns.
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?
Front-loaded with the legal basis and formula, then returns, then caveats and the sibling pointer. It is dense and each sentence carries information (deadline, alternative, indexation), though the opening formula sentence is long and could be split for readability.
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 helpfully enumerates the return fields, and with annotations covering safety and a fully documented 5-param schema, an agent has what it needs to call this correctly. Only the format/units of the returned values remain unstated.
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 baseline is 3, but the description adds genuine meaning by warning that salary indexation during the calculation period must be folded into earnings_12m by the caller. That is a non-obvious semantic constraint not present in the schema, lifting it above 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 resource (vacation pay / отпускные) with its governing legal basis and the exact computation it performs, including the formula. It explicitly distinguishes itself from the sibling unused_vacation_compensation, so an agent can tell the two apart 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?
Routes the agent explicitly to unused_vacation_compensation for dismissal compensation and closes with 'Только вычисление' to signal a pure calculation with no side effects. It does not, however, state when to prefer salary_calc or ndfl_calc over this tool, so alternative coverage is partial rather than exhaustive.
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.0ndfl_calcpayroll_paramssalary_calcsalary_from_netsick_leave_payunused_vacation_compensationvacation_payScored across 7 tools
Each tool has a distinct calculation purpose, and descriptions explicitly cross-reference each other (salary_calc vs salary_from_net as forward/reverse, ndfl_calc as standalone tax, vacation_pay vs unused_vacation_compensation). An agent can reliably pick the right tool.
Consistent snake_case throughout, but the suffix convention is mixed (_calc for salary_calc/ndfl_calc vs _pay for vacation_pay/sick_leave_pay). Still readable and predictable enough.
Seven tools is well-scoped for a payroll calculator domain, with each tool covering a distinct calculation or reference need without redundancy.
Covers the core payroll lifecycle: gross/net conversion, tax, vacation pay, termination compensation, sick leave, and reference params. Minor gaps remain (child deductions explicitly excluded, no severance or multi-employee/batch support).
Verified 2026 Canadian payroll math: employer total cost, employee take-home, net-to-gross. Free.
Net pay to the cent, every deduction and the employer's cost for Germany and the UK, computed with…
Live US paycheck and payroll-tax math for 2026, all 50 states and DC, powered by tools-berry.com.
Russian company lookup (EGRUL/INN), Cyrillic search, RU page to Markdown. Pay per call in USDC.
