de en es ja ko ru zh

depreciation-mcp

Name: depreciation-mcp
Author: boam79

by boam79

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

depreciation-mcp

Сервер, предоставляющий справочные значения сроков полезного использования, амортизации и налоговых корректировок основных средств на основе Закона о корпоративном налоге через Model Context Protocol (MCP).

Результаты расчетов предназначены только для справки. Для подачи отчетности и бухгалтерского учета необходимо учитывать применимое законодательство, фактические обстоятельства и консультации экспертов.

Контекст PRD (MCP-DEP-001-v1)

Нижеприведенные обзор проекта, определение проблемы, целевые пользователи и ключевые сценарии пользователей являются переносом глав 1, 2, 3 и 6 из PRD MCP для расчета амортизации объектов v1.0 (исправленная версия) для README.

1. Обзор проекта

Амортизация основных средств — это ключевая практическая задача, которая повторяется при закрытии периода и подаче декларации по корпоративному налогу. Однако на практике постоянно возникают следующие проблемы:

Необходимо вручную искать [Приложения 5 и 6] к Правилам исполнения для определения срока полезного использования по типу актива.
Бухгалтерия или административный отдел полагаются на формулы в электронных таблицах.
Процессы выбора метода (линейный/ускоренный), проверки диапазона срока полезного использования и расчета налоговых корректировок разделены, что усложняет работу.
При смене ответственного лица критерии принятия решений не сохраняются, что снижает последовательность.

Цель данного MCP — стандартизировать этот процесс, чтобы при вводе информации об активе пользователь получал последовательный результат: поиск срока полезного использования по закону → расчет амортизации → справочные значения налоговых корректировок → пакетная обработка и сравнительный анализ.

2. Определение проблемы

2.1 Неудобства в текущей практике

Повторяемость поиска законодательства Необходимо каждый раз вручную проверять классификацию активов и стандартные сроки по отраслям.
Непоследовательность расчетов Для одного и того же актива разные сотрудники могут применять разные сроки полезного использования или формулы.
Раздельное управление налоговыми корректировками Необходимо отдельно рассчитывать разницу между бухгалтерской амортизацией и налоговым лимитом амортизации.
Неэффективность обработки множества активов В сезон закрытия отчетности приходится многократно рассчитывать десятки активов.
Сложность сравнительного анализа по отраслям Требуется много ручной работы для проверки одного и того же актива по критериям разных отраслей.

3. Целевые пользователи

Группа пользователей	Основные активы	Основные потребности
Администрация больниц/медучреждений	Медицинское оборудование, оборудование зданий, транспорт	Проверка срока полезного использования и метода амортизации дорогих активов
Бухгалтерия производственных компаний	Станки, заводское оборудование, транспорт	Расчет по методу уменьшаемого остатка и налоговые корректировки
Администрация IT/сервисных компаний	Серверы, сетевое оборудование, ПО, мебель	Стандартизация классификации активов и сроков полезного использования
Руководители/бухгалтеры МСП	Транспорт, инвентарь, офисное оборудование	Быстрый и безошибочный расчет по стандартам
Ответственные за закрытие отчетности	Портфель из множества активов	Пакетный расчет и проверка сводных таблиц

4. Ключевые сценарии пользователей (Глава 6 PRD)

Сценарий A — Поиск срока полезного использования медицинского оборудования

Пользователь:

«Скажи, какой срок полезного использования у аппарата МРТ, если рассматривать его по стандартам медицинской отрасли?»

Поток обработки:

Вызов get_useful_life
Поиск по коду Q86 + критерии медицинского оборудования
Возврат стандартного срока, допустимого диапазона, метода амортизации и правового обоснования

Сценарий B — Расчет амортизации отдельного актива

Пользователь:

«Рассчитай график амортизации для актива стоимостью 1,5 млрд вон, приобретенного 01.03.2026, со сроком полезного использования 5 лет.»

Поток обработки:

Вызов calc_depreciation_schedule
Расчет по соответствующему методу (линейный/уменьшаемого остатка/производственный)
Возврат ежегодных сумм амортизации, балансовой стоимости и накопленной амортизации

Сценарий C — Расчет налоговых корректировок

Пользователь:

«Покажи разницу между бухгалтерской амортизацией и налоговым лимитом.»

Поток обработки:

Вызов calc_tax_adjustment
Расчет суммы, не признаваемой в расходах, недоиспользованного лимита и суммы для последующего признания
Возврат с пояснительной запиской

Сценарий D — Пакетная обработка активов в сезон закрытия

Пользователь:

«Рассчитай сразу 50 активов и сделай сводку по годовой амортизации и сумме, не признаваемой в расходах.»

Поток обработки:

Вызов calc_bulk_depreciation
Выполнение расчетов по каждому активу
Возврат сводки по общей амортизации, общему налоговому лимиту и общей сумме, не признаваемой в расходах

Сценарий E — Сравнение отраслей

Пользователь:

«Сравни серверное оборудование по стандартам медицинской отрасли и отрасли разработки ПО.»

Поток обработки:

Вызов compare_industry_life
Сравнение сроков полезного использования и ежегодной амортизации по отраслям
Возврат сравнительной таблицы

Related MCP server: ko-stock-mcp

Требования

Node.js 20 или выше
pnpm 9 или выше (или активация pnpm через npm/corepack)

Установка (общая)

После клонирования репозитория установите зависимости и выполните сборку.

git clone https://github.com/boam79/depreciation-mcp.git
cd depreciation-mcp
pnpm install
pnpm run build

После завершения сборки исполняемый файл будет находиться по пути dist/index.js. (dist/ не включен в репозиторий, поэтому обязательно выполните pnpm run build локально)

Режим разработки (запуск без сборки)

pnpm exec tsx src/index.ts

Как подключить к Cursor AI

1) Файл глобальных настроек MCP

В Cursor перейдите в Settings → MCP или откройте файл настроек JSON напрямую.
В macOS настройки MCP пользователя обычно находятся по пути: ~/.cursor/mcp.json
Добавьте следующий блок в mcpServers. Путь в args должен быть абсолютным путем к папке, которую вы клонировали и собрали на своем ПК.

{
  "mcpServers": {
    "depreciation-mcp": {
      "command": "node",
      "args": ["/절대경로/depreciation-mcp/dist/index.js"]
    }
  }
}

Пример (если папка находится в Downloads):

"depreciation-mcp": {
  "command": "node",
  "args": ["/Users/본인계정/Downloads/depreciation-mcp/dist/index.js"]
}

Полностью закройте и перезапустите Cursor.
Если в чате в списке инструментов MCP появились get_useful_life, calc_depreciation_schedule и т.д., значит подключение успешно.

2) Для конкретного проекта (опционально)

Если вы используете рабочую область с файлом .cursor/mcp.json в корне проекта, вы можете добавить тот же JSON в этот файл. (Путь к UI может отличаться в зависимости от версии Cursor.)

3) Подключение через `tsx` без сборки (опционально)

"depreciation-mcp": {
  "command": "pnpm",
  "args": ["exec", "tsx", "/절대경로/depreciation-mcp/src/index.ts"],
  "cwd": "/절대경로/depreciation-mcp"
}

Как подключить к Claude Desktop (macOS)

Закройте Claude Desktop.
Откройте файл настроек: ~/Library/Application Support/Claude/claude_desktop_config.json
Если mcpServers отсутствует в корне, создайте его и добавьте следующее:

{
  "mcpServers": {
    "depreciation-mcp": {
      "command": "node",
      "args": ["/절대경로/depreciation-mcp/dist/index.js"]
    }
  }
}

Сохраните файл и перезапустите Claude Desktop.
Проверьте, отображаются ли инструменты MCP в новом чате.

Пользователи Windows должны проверить путь к файлу настроек в официальной документации Claude и аналогично настроить command / args.

Предоставляемые инструменты (6)

Инструмент	Описание
`get_useful_life`	Срок полезного использования, допустимый диапазон, базовый метод амортизации по типу актива/отрасли/конструкции здания
`calc_depreciation_schedule`	График линейной/уменьшаемого остатка/производственной амортизации
`calc_tax_adjustment`	Разница между бухгалтерским и налоговым лимитом (простая модель: не признаваемые расходы, недоиспользованный лимит, последующее признание)
`list_asset_categories`	Список классификаций активов
`calc_bulk_depreciation`	Пакетный расчет и сводка до 100 активов
`compare_industry_life`	Сравнение сроков полезного использования и амортизации по отраслям

Скрипты

Команда	Описание
`pnpm run build`	TypeScript → `dist/`
`pnpm start`	`node dist/index.js` (stdio MCP)
`pnpm run dev`	`tsx src/index.ts`
`pnpm test`	Vitest
`pnpm smoke`	Проверка подключения stdio, 6 инструментов и вызов примера `get_useful_life`

Тестирование подключения (локально)

После сборки в корне проекта:

pnpm smoke

Если отображаются OK: listTools и OK: get_useful_life, значит процесс сервера MCP и протокол работают нормально.

О данных

src/data/annex5.ts, annex6.ts и т.д. — это сводные данные для вспомогательных целей. При изменении законодательства обновите содержимое и проверьте его с помощью pnpm test.

Репозиторий

https://github.com/boam79/depreciation-mcp

Available Tools

6 tools

calc_bulk_depreciation일괄 감가상각C

최대 100건, 회계 스케줄 vs 세무 기본 스케줄로 당기 손금부인 등 요약

ParametersJSON Schema

Name	Required	Description
`assets`	Yes	자산 목록
`fiscal_year`	Yes
`output_format`	No

TDQS

C2.6/5.0

Behavior2/5

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

Description provides minimal behavioral context: limit of 100 assets, comparison of accounting vs tax schedules, and a summary output. No disclosure of whether the tool mutates data, requires authentication, or any side effects. Since no annotations exist, the description should carry the full burden but fails to cover key traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single sentence, very concise, but it omits structure like a separate purpose statement or parameter details. It is not excessively long, but the brevity sacrifices completeness. A more structured format would improve usefulness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, nested objects, and no output schema, the description lacks crucial details: what the summary contains, how to interpret the output, and any prerequisites. The tool is moderately complex but the description does not adequately inform an agent how to use it or what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 3 parameters with only 33% description coverage (only 'assets' has label '자산 목록'). The tool description adds no parameter-level context; it does not explain fiscal_year or output_format beyond the enum values. Despite low coverage, the description does not compensate, leaving parameter semantics unclear.

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?

Description indicates bulk depreciation calculation for up to 100 assets, comparing accounting and tax schedules, producing a summary including tax deduction denial. This differentiates from sibling tools like calc_depreciation_schedule (likely single asset) and calc_tax_adjustment (likely more detailed adjustment). However, the phrasing '등 요약' is vague, slightly reducing clarity.

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?

No explicit when-to-use or when-not-to-use guidance. No mention of alternatives or prerequisites. The description implies bulk usage via '최대 100건' but does not clarify when to choose this tool over calc_depreciation_schedule or calc_tax_adjustment.

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

calc_depreciation_schedule감가상각 스케줄B

단일 자산의 정액법·정률법·생산량비례법 스케줄(연도별)

ParametersJSON Schema

Name	Required	Description
`asset_name`	Yes	자산명
`asset_type`	Yes	자산 유형(내용연수 자동참조 시 사용)
`industry_code`	No
`cost`	Yes	취득가액
`acquired_date`	Yes	취득일 YYYY-MM-DD
`method`	No	미입력 시 내용연수 조회 결과의 기본 상각방식
`useful_life_years`	No	미입력 시 업종·자산 기준 표준 내용연수
`total_units`	No
`current_units`	No

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so description carries full burden. It only states the calculation without disclosing side effects, permissions, output format, or behavior on invalid inputs. Minimal transparency for a tool with 9 parameters.

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?

Single sentence, front-loaded with key info (single asset, methods, yearly). Every word is functional, but could be slightly expanded for clarity without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters and no output schema, the description fails to explain the schedule's structure (e.g., yearly breakdown columns, totals) or return format. Lacks completeness for a tool of this complexity.

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 67% (6 of 9 parameters have descriptions). The description does not add meaning beyond schema; it merely lists methods. No explanation of parameter interplay or defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states single asset and three depreciation methods (정액법·정률법·생산량비례법) and yearly schedule. The name and description contrast with sibling `calc_bulk_depreciation`, clearly differentiating scope.

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

Usage Guidelines3/5

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

The description implies single-asset usage but does not explicitly state when to choose this over siblings like `calc_bulk_depreciation` or `compare_industry_life`. No when-not or alternative guidance provided.

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

calc_tax_adjustment세무조정 참고B

회계 감가상각비 vs 세무 상각범위액 → 손금부인·시인부족·추인(단순모형)

ParametersJSON Schema

Name	Required	Description
`book_depreciation`	Yes
`tax_limit`	Yes
`carried_over_denial`	No	전기 이월 손금부인액

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions the tool computes specific adjustments but does not disclose side effects, return format, error handling, or assumptions. The description is minimal and lacks behavioral details.

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?

The description is very concise, capturing the core purpose in a single line. However, it is not structured to highlight parameter usage or provide additional context. It is front-loaded but benefits could be improved with parameter mapping.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has three parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, how to use the carried_over_denial parameter, or any assumptions of the simple model. Context is lacking for an agent to correctly invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one of three parameters has a description in the schema, and the description does not explain any parameters. The Korean text hints at book depreciation and tax limit but does not map explicitly to the schema parameters. With low schema coverage (33%), the description fails to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compares accounting depreciation vs tax depreciation limit and computes adjustments like denial, shortfall, and carryforward. It distinguishes from sibling tools like calc_bulk_depreciation and calc_depreciation_schedule which focus on different aspects of depreciation.

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

Usage Guidelines3/5

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

The description implies usage for tax adjustment calculations but does not explicitly state when to use this tool versus alternatives like calc_bulk_depreciation or get_useful_life. No guidance on prerequisites or exclusions is provided.

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

compare_industry_life업종 간 내용연수·상각 비교B

동일 자산·취득가에 대해 업종별 표준 내용연수 및 1년차·5년 누적 상각(비교용)

ParametersJSON Schema

Name	Required	Description	Default
`asset_type`	Yes
`cost`	Yes
`industry_codes`	Yes
`method`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description only states what the tool does without disclosing behavioral traits such as output format, precision, or any side effects. The description does not compensate for the missing annotations.

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?

The description is a single concise sentence that front-loads the purpose. However, it could be slightly more structured by including parameter information without being overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description lacks completeness. It does not explain the output format, how results are presented for multiple industries, or additional context needed for correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the description only vaguely mentions 'asset and acquisition cost' and 'by industry', failing to provide meaningful details about the four parameters, their enumerations, or how to use them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description explicitly state the tool compares standard useful life and depreciation across industries for a given asset and cost. It clearly differentiates from siblings like calc_depreciation_schedule (full schedule) and get_useful_life (single value).

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

Usage Guidelines3/5

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

The description implies the use case of cross-industry comparison but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

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

get_useful_life내용연수 조회B

자산 유형·업종·건물구조 기준 기준내용연수·허용범위·기본 상각방식·법적근거

ParametersJSON Schema

Name	Required	Description
`asset_type`	Yes	자산 유형
`industry_code`	No	KSIC 스타일 코드 (예: Q86, J62). 미입력 시 별표5 공통
`structure`	No	건물(asset_type=building)일 때 구조

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It does not explicitly state that the tool is read-only, nor does it disclose behavior for missing inputs or errors. The description only lists outputs without behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the key criteria and outputs. No unnecessary words; every element earns its place.

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?

For a retrieval tool with no output schema, the description lists the four output fields (standard useful life, allowable range, default depreciation method, legal basis), which is fairly complete. Missing details on output format or typical use cases, but overall adequate for simple lookup.

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?

Input schema has 100% description coverage, so baseline is 3. The description adds little beyond the schema; it repeats the criteria but does not explain output format or parameter interactions beyond what the schema already provides.

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?

The description clearly states the criteria (asset type, industry, building structure) and outputs (standard useful life, allowable range, default depreciation method, legal basis). It distinguishes from sibling calculation tools by being a retrieval tool, but could explicitly state 'lookup' or 'retrieve' for clarity.

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?

No guidance on when to use this tool versus alternatives. The sibling tools are all calculation-oriented (calc_bulk_depreciation, etc.), but the description does not explicitly direct the agent to use get_useful_life for retrieval and the others for computations.

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

list_asset_categories자산 분류 목록B

업종별(또는 공통) 자산 분류·내용연수·상각률 요약

ParametersJSON Schema

Name	Required	Description	Default
`industry_code`	No
`asset_filter`	No
`show_rates`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral details such as read-only nature, default behavior with empty parameters, or the scope of data returned. This is a significant gap for a list tool.

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?

The description is a single concise sentence that front-loads the key purpose. However, it could be more structured with details, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of schema descriptions, annotations, and output schema, the description is far from complete. It does not explain parameter usage, output format, or provide enough context for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% coverage with no descriptions, and the tool description does not explain any parameter semantics (e.g., industry_code format, asset_filter enum meaning, show_rates effect). The description adds no value beyond parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides a summary of asset classifications, useful lives, and depreciation rates by industry (or common), which distinguishes it from sibling calculation tools.

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

Usage Guidelines3/5

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 calc_depreciation_schedule. Usage is implied as a lookup tool, but no when-not or alternative recommendations are given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.0.0May 3, 2026
- First observedcalc_bulk_depreciation
- First observedcalc_depreciation_schedule
- First observedcalc_tax_adjustment
- First observedcompare_industry_life
- First observedget_useful_life
- First observedlist_asset_categories

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-05-03 01:20 across 6 tools

Disambiguation5/5

Each tool targets a distinct function: bulk calculation, single schedule, tax adjustment, industry comparison, useful life lookup, and category listing. No overlap in purpose.

Naming Consistency5/5

All tools use snake_case with a consistent verb_noun pattern (calc_, compare_, get_, list_). No mixing of conventions.

Tool Count5/5

6 tools is well-scoped for a depreciation-focused server, covering core calculations, lookups, and comparisons without being excessive.

Completeness4/5

Covers key operations: schedule calculation, bulk processing, tax adjustment, useful life retrieval, and category listing. Minor gap: no explicit method for depreciation method enumeration, but still highly functional for its purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

asset-register A
io.github.theluckystrike
Fixed assets and depreciation from bundled Polish KST, HMRC and IRS MACRS tables.
Finance ERP Systems
91
XBOSS B
kr.xdata
Korean national tax and social insurance filings, invoices and payroll data as MCP tools.
Finance ERP Systems Payments & Billing
2661
MyDART A
kr.eocpa
Powerful OpenDART API-based Korean corporate disclosure tools for accounting professionals
Finance Legal & Compliance Open Data
151
MyKIFRS A
kr.eocpa
Full-text search over K-IFRS/K-GAAP standards and KASB accounting Q&A for Korean accountants
Search Documentation Access
62

Related MCP Servers

taxlaw-nts-mcp
Government Data Legal & Compliance Search
kim-go-chon
A
license
A
quality
B
maintenance
Enables searching and retrieving tax law data from the Korean National Tax Service database, including interpretations, rulings, forms, publications, and site menus via MCP tools.
Updated a month ago (2026-09-10 05:24 UTC)
14
1
MIT
ko-stock-mcp
Finance Government Data
okdoittttt
A
license
A
quality
D
maintenance
Provides Korean stock market data, including DART electronic disclosures and KRX trading information, enabling users to query company profiles, financial statements, and stock trade details via MCP clients.
Updated 3 months ago (2026-07-04 01:58 UTC)
9
MIT
mcp-finance-tools
Finance
jack200250-collab
F
license
A
quality
D
maintenance
Provides Korean-specific financial calculators (4 insurances, salary net, severance pay, capital gains tax, DSR/DTI, FX conversion, housing subscription score) as MCP tools for AI agents.
Updated 3 months ago (2026-07-12 03:22 UTC)
7
-
kasb-accounting-mcp
Legal & Compliance Search Databases
myheart9393-svg
F
license
Not graded
quality
B
maintenance
MCP server for searching and retrieving Korean accounting standards (K-IFRS, general corporate accounting standards) and Q&A summaries from the KASB database. Provides four tools: keyword search of standards and Q&As, real-time full text of standards, and cached Q&A details.
Updated 11 days ago (2026-10-04 22:11 UTC)
-

depreciation-mcp

Контекст PRD (MCP-DEP-001-v1)

1. Обзор проекта

2. Определение проблемы

2.1 Неудобства в текущей практике

3. Целевые пользователи

4. Ключевые сценарии пользователей (Глава 6 PRD)

Сценарий A — Поиск срока полезного использования медицинского оборудования

Сценарий B — Расчет амортизации отдельного актива

Сценарий C — Расчет налоговых корректировок

Сценарий D — Пакетная обработка активов в сезон закрытия

Сценарий E — Сравнение отраслей

Требования

Установка (общая)

Режим разработки (запуск без сборки)

Как подключить к Cursor AI

1) Файл глобальных настроек MCP

2) Для конкретного проекта (опционально)

3) Подключение через tsx без сборки (опционально)

Как подключить к Claude Desktop (macOS)

Предоставляемые инструменты (6)

Скрипты

Тестирование подключения (локально)

О данных

Репозиторий

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

3) Подключение через `tsx` без сборки (опционально)