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

Es un servidor que proporciona valores de referencia para la vida útil, depreciación y ajustes fiscales de activos fijos basados en la Ley del Impuesto de Sociedades a través del Model Context Protocol (MCP).

Los resultados de los cálculos son solo para referencia. Las declaraciones y el tratamiento contable requieren la aplicación de la legislación vigente, el análisis de los hechos y la revisión de expertos.

Antecedentes del PRD (MCP-DEP-001-v1)

La siguiente descripción general del proyecto, definición del problema, usuarios objetivo y escenarios clave de usuario son una adaptación de los capítulos 1, 2, 3 y 6 del PRD MCP de cálculo de depreciación de instalaciones v1.0 (revisado) para este README.

1. Descripción general del proyecto

La depreciación de activos fijos es una tarea práctica fundamental que se realiza repetidamente durante el cierre contable y la declaración del impuesto de sociedades. Sin embargo, en la práctica real, se repiten los siguientes problemas:

Es necesario buscar manualmente las tablas [Anexo 5 y 6] de las normas de aplicación para verificar la vida útil según el tipo de activo.
Los equipos de contabilidad o administración general dependen de fórmulas en hojas de cálculo.
La selección del método de línea recta/saldo decreciente, la revisión del rango de vida útil y el cálculo de ajustes fiscales están separados, lo que hace que el trabajo sea tedioso.
Cuando cambia el responsable, no quedan criterios de juicio, lo que reduce la consistencia.

Este MCP tiene como objetivo estandarizar este proceso para que, una vez que el usuario ingrese la información del activo, se proporcione de manera consistente desde la consulta de vida útil basada en la Ley del Impuesto de Sociedades → cálculo de depreciación → valores de referencia de ajuste fiscal → procesamiento por lotes y análisis comparativo.

2. Definición del problema

2.1 Inconvenientes en la práctica actual

Repetitividad de la consulta legal Es necesario verificar manualmente la clasificación de activos y la vida útil estándar por industria cada vez.
Inconsistencia en los cálculos Incluso para el mismo activo, se pueden aplicar diferentes vidas útiles o fórmulas de cálculo según el responsable.
Gestión separada de ajustes fiscales Es necesario calcular por separado la comparación entre el gasto por depreciación contable y el límite de depreciación fiscal.
Ineficiencia en el procesamiento de múltiples activos Durante la temporada de cierre, se deben calcular repetidamente decenas de activos.
Dificultad en la revisión comparativa por industria Se requiere mucho trabajo manual para revisar el mismo activo bajo diferentes estándares industriales.

3. Usuarios objetivo

Grupo de usuarios	Activos principales	Necesidades principales
Equipo administrativo de hospitales/instituciones médicas	Equipos médicos, instalaciones auxiliares de edificios, vehículos	Revisión de vida útil y método de depreciación de activos de alto valor
Equipo contable de empresas manufactureras	Maquinaria, instalaciones de fábrica, vehículos	Cálculo basado en el método de saldo decreciente y ajustes fiscales
Equipo administrativo de empresas de TI/servicios	Servidores, equipos de red, software, mobiliario	Estandarización de clasificación de activos y vida útil
Representantes/contadores de PYMES	Vehículos, suministros, equipos de oficina	Cálculo de estándares rápido y sin errores
Responsables de cierre contable	Portafolio de múltiples activos	Cálculo por lotes y verificación de tablas resumen

4. Escenarios clave de usuario (Capítulo 6 del PRD)

Escenario A — Consulta de vida útil de equipos hospitalarios

Usuario:

"Dime cuántos años de vida útil tiene un equipo de resonancia magnética (MRI) según el sector médico."

Flujo de procesamiento

Llamada a get_useful_life
Consulta basada en Q86 + dispositivos médicos
Retorno de vida útil estándar, rango permitido, método de depreciación y base legal

Escenario B — Cálculo de depreciación de un activo individual

Usuario:

"Calcula el cronograma de depreciación para un valor de adquisición de 1.500 millones, fecha de adquisición 2026-03-01, vida útil de 5 años."

Flujo de procesamiento

Llamada a calc_depreciation_schedule
Cálculo según el método correspondiente (línea recta/saldo decreciente/proporcional a la producción)
Retorno de gasto por depreciación anual, valor contable y valor acumulado

Escenario C — Cálculo de ajuste fiscal

Usuario:

"Dime la diferencia entre el gasto por depreciación contable y el límite de depreciación fiscal."

Flujo de procesamiento

Llamada a calc_tax_adjustment
Cálculo de gastos no deducibles, insuficiencia de reconocimiento y montos sujetos a reversión
Retorno junto con una nota explicativa

Escenario D — Procesamiento por lotes de múltiples activos en temporada de cierre

Usuario:

"Calcula 50 activos a la vez y resume el gasto por depreciación anual y los gastos no deducibles."

Flujo de procesamiento

Llamada a calc_bulk_depreciation
Ejecución de cálculos por activo
Retorno de resumen de gasto total por depreciación, límite fiscal total y total de gastos no deducibles

Escenario E — Comparación entre industrias

Usuario:

"Compara el mismo equipo de servidor bajo los estándares de la industria médica y la industria de software."

Flujo de procesamiento

Llamada a compare_industry_life
Comparación de vida útil por industria y diferencia de depreciación anual
Retorno de tabla comparativa

Related MCP server: ko-stock-mcp

Requisitos

Node.js 20 o superior
pnpm 9 o superior (o activar pnpm con npm/corepack)

Instalación (Común)

Después de clonar el repositorio, proceda con la instalación de dependencias y la compilación.

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

Una vez finalizada la compilación, el archivo ejecutable es dist/index.js. (dist/ no está incluido en el repositorio, por lo que es obligatorio ejecutar pnpm run build localmente)

Modo de desarrollo (ejecución sin compilación)

pnpm exec tsx src/index.ts

Cómo conectar a Cursor AI

1) Archivo de configuración global de MCP

En Cursor, vaya a Settings → MCP o abra el JSON de configuración directamente.
En macOS, la configuración de MCP del usuario suele estar en la siguiente ruta: ~/.cursor/mcp.json
Agregue el siguiente bloque dentro de mcpServers. La ruta en args debe ser la ruta absoluta de la carpeta que clonó y compiló en su PC.

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

Ejemplo (si se colocó en la carpeta de descargas):

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

Cierre Cursor completamente y vuelva a abrirlo.
Si ve herramientas MCP como get_useful_life, calc_depreciation_schedule, etc., en el chat, significa que está conectado.

2) Específico del proyecto (opcional)

Si es un espacio de trabajo que utiliza .cursor/mcp.json en la raíz del proyecto, puede colocar el mismo JSON en ese archivo. (La ruta de la interfaz de usuario puede variar según la versión de Cursor).

3) Conexión con `tsx` sin compilación (opcional)

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

Cómo conectar a Claude Desktop (macOS)

Cierre Claude Desktop.
Abra el archivo de configuración: ~/Library/Application Support/Claude/claude_desktop_config.json
Si no existe mcpServers en la raíz, créelo y agregue lo siguiente:

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

Guarde el archivo y reinicie Claude Desktop.
Verifique si las herramientas MCP aparecen en una nueva conversación.

Los usuarios de Windows deben verificar la ruta del archivo de configuración en la documentación oficial de Claude y configurar command / args de la misma manera.

Herramientas proporcionadas (6)

Herramienta	Descripción
`get_useful_life`	Vida útil, rango permitido y método de depreciación básico según tipo de activo, industria y estructura del edificio
`calc_depreciation_schedule`	Cronograma de línea recta, saldo decreciente y proporcional a la producción
`calc_tax_adjustment`	Diferencia entre contabilidad vs límite fiscal (modelo simple de no deducibilidad, insuficiencia de reconocimiento, reversión)
`list_asset_categories`	Lista de categorías de activos
`calc_bulk_depreciation`	Procesamiento por lotes y resumen de hasta 100 activos
`compare_industry_life`	Comparación de vida útil y depreciación por industria

Scripts

Comando	Descripción
`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`	Verificación de conexión stdio, 6 herramientas y llamada de muestra `get_useful_life`

Prueba de conexión (local)

Después de compilar, en la raíz del proyecto:

pnpm smoke

Si aparece OK: listTools y OK: get_useful_life, el proceso del servidor MCP y el protocolo son correctos.

Sobre los datos

src/data/annex5.ts, annex6.ts, etc., son datos resumidos para asistencia práctica. Actualice el contenido cuando se modifique la legislación y verifique con pnpm test.

Repositorio

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

Antecedentes del PRD (MCP-DEP-001-v1)

1. Descripción general del proyecto

2. Definición del problema

2.1 Inconvenientes en la práctica actual

3. Usuarios objetivo

4. Escenarios clave de usuario (Capítulo 6 del PRD)

Escenario A — Consulta de vida útil de equipos hospitalarios

Escenario B — Cálculo de depreciación de un activo individual

Escenario C — Cálculo de ajuste fiscal

Escenario D — Procesamiento por lotes de múltiples activos en temporada de cierre

Escenario E — Comparación entre industrias

Requisitos

Instalación (Común)

Modo de desarrollo (ejecución sin compilación)

Cómo conectar a Cursor AI

1) Archivo de configuración global de MCP

2) Específico del proyecto (opcional)

3) Conexión con tsx sin compilación (opcional)

Cómo conectar a Claude Desktop (macOS)

Herramientas proporcionadas (6)

Scripts

Prueba de conexión (local)

Sobre los datos

Repositorio

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

3) Conexión con `tsx` sin compilación (opcional)